Moin,
* Markus Schulz wrote (2005-11-22 20:11):
>Am Dienstag, 22. November 2005 16:55 schrieb Thorsten Haude:
>> * Markus Schulz wrote (2005-11-22 16:37):
>> >Und genau hier ist mir der Wechsel des DBMS nicht mehr möglich wenn
>> > das neue keine Trigger gestattet. Denn der Nachbau von Triggern in
>> > der Abstraktionsschicht ist nicht mehr möglich.
>>
>> Warum das denn nicht?
>
>Ich versuch mal meine Sicht an einem ganz einfachem Bsp. zu schildern:
>Ich habe ein DB-Modell und eine Menge X an Funktionen/Strukturen in PHP
>die meine API für die Clients (Web und Standalone) bilden.
>Im Falle von Postgres, liefert die PHP API einfach nur das Ergebnis der
>entsprechenden plpgsql-Funktion mit konvertierten Datentypen.
>Wenn ich dagegen Mysql oder ähnlich funktionsarme DBMS verwende,
>implementiere ich die notwendigen Funktionen mittels PHP kombiniert mit
>SQL Abfragen an Mysql.
>In diesem Interface kann ich vieles Nachbilden, einiges aber nur mit
>großem Aufwand, z.B. cascadiertes Löschen/updaten ist verdammt
>aufwendig.
Das ist unbestritten, aber nicht das gleiche wie "nicht mehr möglich".
>Für plpgsql ist da nichts zu tun, das erledigt das DBMS von
>allein. Gleiches gilt für Trigger.
Bei Triggern sehe ich kein größeres Problem, solange man nicht SQL
benutzt, um auf die DB zuzugreifen, sondern einen Satz Funktionen der
Mittelschicht. Ok, das würde man ohne Not vielleicht nicht machen,
sollte aber auch nicht schwierig zu implementieren sein.
>Dagegen läßt sich der Code einer plpgsql Funktion recht leicht in php
>+ sql querys umsetzen.
Solange man die Stored Procedures nicht zu dicht mit der DB
verschmelzt, was aber irgendiwe ihr Hauptvorteil ist.
Thorsten
--
The best leaders are those barely known to their followers; after them, those
they love; after them, those they fear; after them, those they despise.
- Lao Tzu
Attachment:
pgps8jtORDxox.pgp
Description: PGP signature