Mailinglist Archive: opensuse-de (4880 mails)

[Jan.Trippler@xxxxxxxxxxx (Jan Trippler)]

Am Montag, 10. November 2003 21:37 schrieb Al Bogner:
[...]
> Gibt es eine Alternative für "if" unter PostgreSQL? Trigger und 
> Stored Procedures werden bei MySQL auch kommen. Mal sehen, ob ich
> bald mit MySQL anstehe und zu PostgreSQL migriere.

Ein IF in SQL? Huch? SQL ist eine _Query-Language_, keine 
Programmiersprache. Ein if gibts in PostgreSQL - da wo es hingehört: In 
die Procedure Language.

Ich hab mir die Seite, die Du genannt hast, mal angeschaut - hm, naja. 
Einige Sachen stimmen IMHO einfach nicht, andere sind etwas - ähm, 
einseitig - dargestellt. Ein paar Beispiele (ich gehe von der 
PostgreSQL-7.2 Doku aus, die ich hier habe, ich nehme an, dass die als 
Vergleich herangezogene 7.3 nicht weniger hat):

- da steht unter *other types*: Datentyp byte gibts bei beiden nicht - 
der Datentyp heisst unter PG bytea, er existiert.
- der Typ *double* findet sich in mysql, in PG nicht. Logo - da heisst 
er nämlich *double precision* - der taucht aber nicht auf.
- Typ *text* existiert angeblich nicht unter PG - Lüge.
- Die Funktion concat existiert nicht in PG - stimmt! Der Standard 
definiert nämlich || als String-Verkettung - daraus folgt gleich 
nochwas: || als *OR*-Ersatz gibt es demzufolge nicht.
- kleine Sachen: Keyword VIEW ex. angeblich nicht, ein paar Absätze oben 
wird aber (korrekt) erwähnt, dass *CREATE VIEW* existiert. Keyword 
*trigger* gibts angeblich auch nicht - komisch: Wieso funktioniert dann 
die *create trigger* Anweisung?
- *Alter table modify column* geht nicht in PG. Stimmt. Heisst "alter 
table alter column* - taucht aber nicht auf.
- *Case insensitive compare* geht nach der Seite nicht - Schwindel. 
Dafür gibts nen ganzen Sack von Möglichkeiten (ilike, regular 
expressions).
- Funktion *Function SUBSTRING as MID* geht nicht - häh? 
substring('einszweidrei' from 5 for 4) liefert 'zwei'.
- Funktion *regexp in select* geht ja auch nicht - wir nehmen da nämlich 
einfach reguläre Ausdrücke (z. B. in like).

Um es mal vorsichtig auszudrücken: Dieser Vergleich erscheint mir nicht 
ganz unparteiisch. Wenn ich bei solchen Vergleichen von den 
mysql-Funktionen, Datentypen, ... ausgehe, dann fällt natürlich in 
jedem Bereich ausser dem ANSI-Standard dieser Vergleich zu Gunsten von 
mysql aus. Dabei wird oft einfach ignoriert, dass viele 
Funktionalitäten mit anderen (nicht genannten) Funktionen realisiert 
wurden. Das ganze Datum- / Zeithandling z .B. läuft in PostgreSQL ganz 
einfach über Operatoren (+, -, *, /) - da brauche ich gar keine 
Funktionen! Das Thema Procedures würde mysql ziemlich blöd dastehen 
lassen, weil Du da in PG fast beliebig Programmiersprachen einbinden 
kannst und so deren gesamten Funktionsumfang nutzen kannst.

Ich will noch hinzufügen, dass ich nicht mysql in Grund und Boden 
verdamme - ich halte das Produkt für durchaus geeignet bei bestimmten 
Anwendungen. Ich würde es nur begrüßen, wenn man _vor_ dem Einsatz mal 
gründlicher nachdenken würde und nicht gleich *mysql, weil - das nehmen 
sie alle* brüllen würde. Für DB-Anwendungen mit höheren Ansprüchen an 
die Qualität des DB-Designs (z. B. kaufmännische Anwendungen) halte ich 
(fast) jede andere SQL-DB für besser geeignet.

Jan

P.S.: *umpf* jedes Mal bei diesem Thema gehen die Gäule mit mir durch ;) 
Dabei haben die anderen DBMS in der Regel eine lange Zeit an 
Produktreife hinter sich, mysql eher nicht.