[linux-l] Was mich an WebApplikationen immer und immerwiderAnkotzt...

[Rocco Rutte]

Hi,

* Steffen Dettmer wrote:
>* Rocco Rutte wrote on Thu, Jul 31, 2008 at 07:48 +0200:

>Ich hab leider im Thread verpasst, warum die Struktur nicht
>stabil ist (erweitern mit neuen Tabellen ist doch erlaubt,
>oder?).

Peter hatte vorgeschlagen für Applikationen mit DB-Storage die 
DB-Struktur zu stabilisieren und darauf aufbauend zu abstrahieren und 
Anwendungen drauf zu schreiben. Ich habe selbst nie wirklich 
CMS-Software aktualisiert, weil mich schon die DB abschreckt sowas zu 
benutzen. Durchschnittliche CMS-Software ist mir zu eigenständig.

>Meinen bescheidenen praktischen Erfahrungen nach lag sowas oft
>daran, dass sich indirekt in der Struktur Implementierungsdetails
>der Anwendung wiederspiegelten. Oft, weil über die direkten
>unmittelbaren Anwendungs-Anforderungen ein "Datenbankmodell"
>gemacht wurde: "Ohh, ich hab hier ein int an meinem Objekt, da
>mach ich mal ein INTEGER Feld in die Tabelle" (wobei das int Feld
>vielleicht schon im Objekt falsch ist).  Überhaupt, so ein 1:1
>mapping ist vermutlich in der Regel falsch (aber es gibt genau
>dafür extra Libraries und Frameworks, die verkaufen einem das
>wohl als Feature?).

>Bei relationalen Datenbanken frage ich mich überhaupt oft, warum
>man oft so gern 1:1 auf Tabellen zugreifen möchte. Vielleicht,
>weil viele Entwickler C oder Java Programmierer sind und
>imperativ denken - und natürlich in 3GL statt 4GL.

Das glaube ich nicht, es denkt für 0815 niemand mehr in SQL, das ist 
alles generiert... :)

Der Vorteil an ORM und 1:1 (oder fast 1:1) ist, dass man den DB Dialekt 
abstrahieren und dann alles SQL automatisch aus den Metainformationen 
der Objekte erzeugen kann (je nach Sprache geht das sogar aus der 
Objekte-Definition selbst heraus, d.h. dass selbst Schreiben von 
Mapping-Definitionen entfällt, und umgekehrt kann man aus der 
DB-Struktur direkt Objekte erzeugen, die sich analog zur DB verhalten 
was Constraints/Referenzen angeht).

Wenn man "irgendeine" Struktur hat, die nicht mehr nah genug an den 
Objekten dran ist, wird das schwieriger bis nicht mehr machbar. Mit zig 
Plugin-Schnittstellen, Modulen und optionalen Features will man sich 
aber vermutlich nicht auch noch um die SQL-Dialekt-Abstraktion kümmern.

Bei selbst gebautem SQL müsste man bestimmte Versionen von bestimmten 
Datenbanken freigeben, d.h. es müsste vorher getestet werden. Aber ich 
bezweifle, dass sich die Logik hinter einer Web 2.0-Anwendung mit hoher 
Abdeckung der Features automatisch durchtesten lässt.

...also nimmt man ORM. Das würde ich übrigens auch tun... :)

Bei Performance-kritischen Sachen fällt ORM eh aus.

>Ist es nicht eigentlich viel logischer, in Gedanken nur views zu
>haben (die sind ja dafür schliesslich da) und u.U. Stored
>Procedures (indirekt via views, z.B. als Trigger oder Regeln oder
>direkt in dem man sie aufruft)?

IHMO das gleiche Problem wie oben. Ist die Logik in (C,Java,Python,Foo) 
Code, ist das eine definierte Umgebung. Für 0815 und Web 2.0 schreibt 
niemand extra Stored Procedures für n Kominationen aus DB+Anwendung. Vor 
allem weil sich Dialekte oft an sehr subtilen Stellen unterscheiden, 
d.h. der gemeinsame Codeanteil ist sehr hoch. Das wäre wartungsmäßig 
Horror für mich.

Views könnte bei read-only funktionieren, allerdings bezweifle ich, dass 
viele DBs ein Rule-System ala Postgres haben, womit man ein INSERT auf 
einen VIEW machen darf. Ansonsten müsste man das über Tabellen und 
Trigger vermutlich simulieren, aber... dann lieber ORM.

MfG, Rocco