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)