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.