Am Dienstag, 22. November 2005 16:55 schrieb Thorsten Haude: > Moin, > > * Markus Schulz wrote (2005-11-22 16:37): > >On Tuesday 22 November 2005 15:27, Thorsten Haude wrote: > >> * Markus Schulz wrote (2005-11-22 15:07): > >> >In jedem zweiten Opensource-Webprojekt Projekt wird es genau so > >> > gemacht. Natürlich kann und sollte man vom DB-Code abstrahieren. > >> > Das spricht jedoch noch absolut nicht gegen den Einsatz von SP. > >> > >> Doch, genau das ist das Hauptargument gegen Stored Procedures, > >> solange man sie nicht einsetzt, um den Zugriff zur DB etwas zu > >> erleichtern. > > > >Warum? Wenn ich eine Schicht habe, die meine Anwendung abstrahiert > > von dem expliziten Aufruf einer SP habe ich doch keine Probleme > > beim Umstieg auf ein anderes DBMS. > > Das bekommst Du eben dann, wenn Du die Stored Procedures nicht 1:1 > auf das neue DBMS übertragen kannst. Wenn Du die DB- und > Geschäftsschicht trennst, hast Du es da erheblich leichter. > > >Und darum ging es doch, das ich im Ernstfall nur in der > >Verbindungsschicht von Anwendung und DBMS die SP eventuell durch SQL > >Code oder ähnliches Ersetzen kann, falls das DBMS mir SP von Haus > > aus nicht bietet. > > "Oder ähnliches" klappt leider nicht so gut, wenn Du die Datenlogik > mit der Geschäftslogik verstrickt hast. Das aber wird einem ja mit > Stored Procedures ja gerade so leicht gemacht. > > >> >Und Trigger empfinde ich als komplizierter zu abstrahieren als > >> > SP. > >> > >> Trigger haben nach außen unsichtbar zu sein. > > > >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 glaube wir haben ein unterschiedliches Verständnis von Abstraktionsschicht. 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. Für plpgsql ist da nichts zu tun, das erledigt das DBMS von allein. Gleiches gilt für Trigger. Dagegen läßt sich der Code einer plpgsql Funktion recht leicht in php + sql querys umsetzen. Aber nochmal, ich würde freiwillig nicht auf Features des DBMS verzichten die mir einen echten Vorteil verschaffen, das war Felix sein anliegen. -- Markus Schulz Ein wenig wie Windows: entweder es geht einfach oder gar nicht.