Von mysql nach postgres

30/04/2012 - 09:44 von Stefan+Usenet | Report spam
Die Moeglichkeiten der Datenbanken sind soweit klar, daher das
Posting in dieser Gruppe. Problemstellung ist die Erweiterung eines
umfangreicheren Stuecks Software mit knapp 1000 Queries und ein paar
Dutzend weiteren SQL-Statements von MySQL-only auch nach Postgres.
Nachdem das fuer Datenstruktur und Inhalte soweit geklappt hat, ist
nun endlich PHP auf die Schnauze gefallen, da sich PostgreSQL naeher
am Standard orientiert und konsequente Kleinschreibung fuer
Tabellen- und Spaltennamen verwendet: die Befuellung diverser
assoziativer Arrays passt nun nicht mehr zum nachfolgenden Code.
Fuer eine Query "SELECT FooBarBaz FROM Test" wird aus ehemals
$row['FooBarBaz'] nun $row['foobarbaz'], was ganz und gar nicht das
gleiche ist. Die Migration wurde daher erst einmal laengerfristig
aufgeschoben, es steht nun allerdings die Frage im Raum welche der
folgenden Moeglichkeiten in weiterer Folge am wenigsten Schmerzen
verursachen wird:

a) PostgreSQL zu case-sensitiven Namen zwingen, was moeglich ist.
Pluspunkt: der Programmcode und MySQL koennen bleiben, wie sie sind.
Negativ: es ist eine Vergewaltigung von PostgreSQL und zudem
weiterhin nicht so recht standardkonform. Unter Umstaenden gibt es
die gleichen Probleme bei der naechsten Datenbank (so die denn
jemals kommt) wieder.

b) Alles auf Kleinschreibung umstellen. Das ist im Programmcode
alles andere als lustig und immens fehleranfaellig; Konstruktoren
werden haeufig mit assoziativen Arrays aufgefuellt, die - allerdings
nicht ausschliesslich - aus der Datenbank befuellt werden,
Folgefehler sind also geradezu vorprogrammiert. Zudem leidet die
Lesbarkeit von Namen wie "supportinvoicepricechangesdown" schon
recht deutlich.

c) weg von assoziativen Arrays. Pluspunkt: Das waere im Prinzip die
korrekte[TM] Loesung, die immer funktioniert. Negativ: Die
Fehleranfaelligkeit waere noch groesser, als im Fall b).
Konstruktoren, die ein Array mit bis zu 50 Komponenten verarbeiten,
lassen sich deutlich einfacher schreiben, wenn man sich nicht bei
jeder Komponente ueberlegen muss, was man da nun eigentlich
angreift, Aenderungen waeren blanker Horror und lesen koennte man
allenfalls noch die (hoffentlich zu 100% aktuellen) Kommentare, aber
nicht mehr den Code selbst.

Momentan tendiere ich - Bequemlichkeit - ein wenig zu Variante a).
Wie wuerdet ihr das machen? Oder gibt es noch weitere Varianten, die
ich schlicht uebersehen habe?

Servus,
Stefan

http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Geht nicht!? Gibt's nicht! Stefan.
(Sloganizer)
 

Lesen sie die antworten

#1 Torsten Zuehlsdorff
30/04/2012 - 12:26 | Warnen spam
On 30.04.2012 09:44, Stefan Froehlich wrote:
Die Moeglichkeiten der Datenbanken sind soweit klar, daher das
Posting in dieser Gruppe. Problemstellung ist die Erweiterung eines
umfangreicheren Stuecks Software mit knapp 1000 Queries und ein paar
Dutzend weiteren SQL-Statements von MySQL-only auch nach Postgres.



Das schreit nach dem DDDBL ;)

Nachdem das fuer Datenstruktur und Inhalte soweit geklappt hat, ist
nun endlich PHP auf die Schnauze gefallen, da sich PostgreSQL naeher
am Standard orientiert[..]



Nàher? Du bist ja euphemisch ;)

[..] und konsequente Kleinschreibung fuer
Tabellen- und Spaltennamen verwendet: die Befuellung diverser
assoziativer Arrays passt nun nicht mehr zum nachfolgenden Code.
Fuer eine Query "SELECT FooBarBaz FROM Test" wird aus ehemals
$row['FooBarBaz'] nun $row['foobarbaz'], was ganz und gar nicht das
gleiche ist.



Du kannst dich hier aber auch an den SQL Standard halten und "quoted
identifier" verwenden. Man muß nicht direkt zu UTF8-Zeichen in
Relationsnamen greifen, aber ein paar Anführungszeichen wirken Wunder:

Ohne Anführungszeichen:

test=# SELECT 1 AS FOO;
foo
1
(1 Zeile)

Und das ganze wie gewünscht:

test=# SELECT 1 AS "FOO";
FOO
1
(1 Zeile)

Die Migration wurde daher erst einmal laengerfristig
aufgeschoben, es steht nun allerdings die Frage im Raum welche der
folgenden Moeglichkeiten in weiterer Folge am wenigsten Schmerzen
verursachen wird:

a) PostgreSQL zu case-sensitiven Namen zwingen, was moeglich ist.
Pluspunkt: der Programmcode und MySQL koennen bleiben, wie sie sind.
Negativ: es ist eine Vergewaltigung von PostgreSQL und zudem
weiterhin nicht so recht standardkonform. Unter Umstaenden gibt es
die gleichen Probleme bei der naechsten Datenbank (so die denn
jemals kommt) wieder.



Wenn ich mich recht entsinne, sagt der SQL 92 Standard, das dies völlig
konform ist (und es làuft sogar unter MySQL). Was PostgreSQL belangt,
gibt es hier die Syntax:
http://www.postgresql.org/docs/9.1/...DENTIFIERS

Gruß,
Torsten

Ähnliche fragen