Re: LAPP statt LAMP?
On Tuesday 22 November 2005 15:27, Thorsten Haude wrote:
> * Markus Schulz wrote (2005-11-22 15:07):
> >On Tuesday 22 November 2005 14:38, Thorsten Haude wrote:
> >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. 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.
> >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. Trigger sind also eher zu
vermeiden als SP. Und nur weil sie nach aussen hin unsichtbar sind,
erledigen sie doch eine Aufgabe. Und genau diese muss beim Einsatz
eines DBMS ohne Trigger Unterstützung ja auch erledigt werden. Hier
fangen die Probleme dann an. Wo wir bei Triggern sind, cascadierende
Foreign-Keys sind da auch ein nettes Beispiel, ich kann mir ein Leben
ohne kaum noch vorstellen. Das ganze in der Abstraktionsschicht zu
implementieren ist Grausam und Fehleranfällig. Ich für meinen Teil
würde nie mehr ein DBMS einsetzen das solche Möglichkeiten nicht
bietet.
> >Würde deine Bedenken also eher genau umgedreht haben. Mir fällt da
> >nämlich keine Mögliche Abstraktion ein wie ich unabhängig vom DBMS
> > in einer Abstraktionsebene Trigger implementiere für DBMS die das
> > von Haus aus nicht beherrschen.
>
> Da gibt's schon Wege, aber ein fehlendes Feature kann man sicher
> nicht in allen Fällen ersetzen. Soll das jetzt heißen, daß ich bei
> Oracle, PostgreSQL, Firebird etc. auf alles verzichten soll, was
> MySQL nicht unterstützt?
Nein, wo sag ich sowas? Im Gegenteil, ich würde immer alles Ausreizen
was mir eine Datenbank bietet solange ich dadurch signifikante Vorteile
bekomme. Wenn bei Postgres z.B. die Vererbung inkl. allen Constraints
funktioniert werden wir sie hier in der Firma auch einsetzen.
Ich wollte nur auf die Gefahr von Triggern im Gegensatz zu SP beim
Wechsel eines DBMS und der dazu notwendigen Abstraktionsebene
hinweisen. Ich für meinen Teil bin auf die Abstraktionsebene nicht
angewiesen _weil_ ich das DBMS wechseln will, sondern um verschiedenen
Client-Applikationen (Standalone + Browser) eine einheitliche
Schnittstelle bieten zu können.
>
> >SP kann man dagegen mit SQL Code umsetzen.
>
> Nur, wenn es eine passende Laufzeitumgebung gibt. MySQL kann SQL,
> aber eben keine Stored Procedures.
Die Abstraktionsebene wird ja wohl nicht in SQL umgesetzt sein, eine
Laufzeitumgebung muss also wohl immer vorhanden sein.
> >> >DBMS wechseln ist schwierig, das gebe ich zu. Allerdings könnte
> >> > man da auch kontern, wer das DBMS wechseln muss hat sich im
> >> > Vorfeld nicht genügend Gedanken in Bezug auf Skalierbarkeit etc
> >> > gemacht.
> >>
> >> Quatsch. Es kann einfach einem proprietären Hersteller einfallen,
> >> in einer neuen Version oder einem Servicepack zu verbieten,
> >> Vogelbilder in der Datenbank zu speichern. Dann steht man da mit
> >> seiner Vogelbildersammlung und muß eine neue Datenbank suchen.
> >> Will sagen: es gibt noch deutlich mehr Gründe, das DBMS zu
> >> wechseln als Leistung.
> >
> >Und trotzdem bleibt der Wechsel eines DBMS nicht ohne Arbeit.
>
> Habe ich dem widersprochen?
Nein, aber darum ging es in meiner Diskussion mit Felix. Und du hast dir
quasi nur den Nebensatz der eigentlichen Aussage rausgepickt :)
> >Und mehr wollte ich nicht sagen.
>
> Da steht implizit, daß man nur wechseln muß, wenn man skalieren muß,
> wenn also die Leistung nicht ausreicht.
da steht: "Skalierbarkeit etc"
Und Gedanken machen kann man sich auch über den Support/Beständigkeit
des DBMS Herstellers. Aber darüber will ich eigentlich garnicht
diskutieren. Mir ging es einzig und allein um: SP und andere
spezifische Features eines DBMS nutzen ja/nein?
Markus
--
"Ich dachte immer, UNIX ist was für Leute, denen es gefällt,
auf einen Bildschirm zu starren, auf dem es aussieht, als
hätte sich gerade ein Gürteltier auf der Tastatur gewälzt."
(Stefan Schneider)
Reply to: