Regualar Expressions für unterschiedliche Funktionen

[tcs_ulli]

Hallo,

Ich arbeite an einem Verwaltungssystem das auf unterschiedlichen Datenbanken läuft.
Dabei wird es langsam zum Standardproblem das es für viele Funktionen auf unterschiedlichen Datenbanken nichtmal ähnliche Funktionen gibt. Mit Funktionen meine ich hier z.b. die Dateums Zeit Routinen o.ä.

Nun ist mir vorhin die Idee gekommen das man warscheinlich mit Regular Expresssions zum ersetzen glattbügeln könnte.

Wenn man quasi von und zu jedem großen Datenbanksystem einen Satz Regualr Expressions für die Unterschiede im SQL hätte wäre das sicherlich sehr nützlich ?!

Gibt es da Leute die ein Interesse daran hätten und zumindest Funktionsequivalente mit sammeln würden ?!

 

[akretschmer]

Ich arbeite an einem Verwaltungssystem das auf unterschiedlichen Datenbanken läuft.
Dabei wird es langsam zum Standardproblem das es für viele Funktionen auf unterschiedlichen Datenbanken nichtmal ähnliche Funktionen gibt. Mit Funktionen meine ich hier z.b. die Dateums Zeit Routinen o.ä.

Ich bin prinzipiell der Meinung, daß das zwar ein edles Ziel ist, in der Praxis aber eine schlechte Idee. Wenn Du das auf N verschiedene Systeme loslassen willst, kannst Du nur das nehmen, was alle verstehen.

Schau Dir http://www.sql-workbench.net/dbms_comparison.html an und überleg, ob das gut ist, was Du planst.

 

[ukulele]

Ich denke auch das ein simples Ersetzen schwer wird, die Syntax kann sehr unterschiedlich und sehr komplex sein. Besser wirst du warscheinlich mit einer vernünftigen Doku fahren.

 

[akretschmer]

Ich denke auch das ein simples Ersetzen schwer wird, die Syntax kann sehr unterschiedlich und sehr komplex sein.

Selbst bei exakt gleicher Syntax kommen unterschiedliche Dinge raus.

MySQL:

mysql> create table demo (id int primary key, val int, check (val < 10));
Query OK, 0 rows affected (0.00 sec)

mysql> insert into demo values (1,5);
Query OK, 1 row affected (0.00 sec)

mysql> insert into demo values (2,15);
Query OK, 1 row affected (0.00 sec)

PostgreSQL:

test=*# create table demo (id int primary key, val int, check (val < 10));
CREATE TABLE
Time: 104,200 ms
test=*# insert into demo values (1,5);
INSERT 0 1
Time: 0,515 ms
test=*# insert into demo values (2,15);
ERROR:  new row for relation "demo" violates check constraint "demo_val_check"
DETAIL:  Failing row contains (2, 15).
Time: 0,264 ms

Meine create - und insert-Befehle sind EXAKT gleich (Copy&Paste), das Resultat komplett unterschiedlich.

MySQL:

mysql> select * from demo;
+----+------+
| id | val  |
+----+------+
|  1 |  5 |
|  2 |  15 |
+----+------+
2 rows in set (0.00 sec)

PostgreSQL:

test=*# select * from demo;
 id | val
----+-----
  1 |  5
(1 row)

Ich könnte da noch weitere Beispiele bringen, kein Problem.

 

[akretschmer]

Ich könnte da noch weitere Beispiele bringen, kein Problem.

MySQL:

mysql> create table master(id int primary key);
Query OK, 0 rows affected (0.00 sec)

mysql> create table slave(master_id int references master);
Query OK, 0 rows affected (0.00 sec)

mysql> insert into slave values (1);
Query OK, 1 row affected (0.00 sec)

PostgreSQL:

test=# create table master (id int primary key);
CREATE TABLE
Time: 3,529 ms
test=*# create table slave (master_id int references master);
CREATE TABLE
Time: 50,503 ms
test=*# insert into slave values (1);
ERROR:  insert or update on table "slave" violates foreign key constraint "slave_master_id_fkey"
DETAIL:  Key (master_id)=(1) is not present in table "master".
Time: 1,561 ms

 

[akretschmer]

Ich könnte da noch weitere Beispiele bringen

einer geht noch, MySQL:

mysql> create table null_test(id int, i int not null);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into null_test(id) values (1);
Query OK, 1 row affected, 1 warning (0.00 sec)

PostgreSQL:

test=*# create table null_test(id int, i int not null);
CREATE TABLE
Time: 12,344 ms
test=*# insert into null_test (id) values (1);
ERROR:  null value in column "i" violates not-null constraint
DETAIL:  Failing row contains (1, null).
Time: 0,279 ms

 

[ukulele]

Das MySQL z.B. CHECK Constraints akzeptiert, dann aber nicht beachtet ist ja kein Problem der Syntax, die ist ja in beiden Fällen richtig. Das Problem kann einen auch bei ausreichender Dokumentation treffen, wenn man nicht weiß was MySQL tut und was nicht.

 

[akretschmer]

Das MySQL z.B. CHECK Constraints akzeptiert, dann aber nicht beachtet ist ja kein Problem der Syntax, die ist ja in beiden Fällen richtig. Das Problem kann einen auch bei ausreichender Dokumentation treffen, wenn man nicht weiß was MySQL tut und was nicht.

Genau. Es reicht nicht, die Syntax anzupassen, daß es auf N verschiedenen Plattformen läuft, man muß deutlich höher in der Anwendung schon wissen, was welches System kann.

 

[tcs_ulli]

Doch reicht das einige dbms constrains nicht checken interessiert bei nem datenimport doch nicht. Da muss man sich halt ein dbms aussuchen das die Features hat die man will. Das muss aber keine Software leisten sondern ein Admin. Für die Software reicht es die Syntax so anzupassen das die Querys laufen.
Aber gut ich hab meine Antwort, kein Interesse.

 

[Walter]

Ich habe so etwas schon einmal realisiert, für eine sehr umfangreiche Software.

Lass Dir gesagt sein, Du stehst vor einer zwar nicht unlösbaren, aber komplexen Aufgabe. SQL-Standard? Vergiss es, jede Datenbank kocht ihr eigenes Süppchen. Funktionen sind da eher noch das geringere Problem, dafür kann man automatische Umsetzungsfunktionen schreiben.

Du musst Dich nicht nur von SQL her auf den kleinsten gemeinsamen Nenner zurückziehen, es lauern auch einige Fallstricke in den Details. Unterschiedliche Datentypen, Datentypen die zwar gleich zu sein scheinen aber teilweise minimal anders reagieren, die Behandlung von NULL-Werten, etc

 

[tcs_ulli]

Naja meine Software existiert ja seit 10 Jahren, iche rlaube nur an einigen Stellen direkt SQL Abfragen zu benutzen. Das mit dem kleinsten gemeinsamen nenner ist schon ne weile für Postgres,MSSql,Firebird und SQLite realisiert. ich würd nur gern weiter in Richtung generische Abfragen ziehn und da haperts jetzt ziemlich in Richtung Datumsfunktionen, die implementiert jeder komplett anders. Und da dacht ich man sammelt etwas das bringt sicher mehr Leuten was.