Re: LAPP statt LAMP?
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.
Reply to: