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

[Steffen Dettmer]

* Rocco Rutte wrote on Thu, Jul 31, 2008 at 07:48 +0200:
> > > Stabile APIs haben sich halt noch nicht ueberall herumgesprochen.
>
> > Die Frage ist, ob und wie sie sich realisieren lassen.
>
> > Das bedarf einer Abstraktion vor der Implementierung.
>
> Genau da ist das manchmal Problem: sie lassen sich wegen der Abstraktion
> nicht stabilisieren.

Ich hatte schon öfter den Eindruck, dass sich APIs wegen
übertriebenen Erweiterbarkeitsideen nicht stabilisieren lassen.
Da werden hooks und so noch und nöcher auf viele Klassen
verteilt, alles ist super kompliziert, damit auch Ausnahmefall X
gehen soll (den man noch nicht kennt). Am Ende muss es dann doch
geändert werden, weil der Ausnahmefall X' kommt. Das ist scheint
bei Java-Libs besonders extrem zu sein (bei Java selbst gehts,
weil die alten APIs meist mitgeschleppt werden).

Wenn man dann am Ende ne Abstraktion in der Form "Binärdaten,
Länge" oder "freie XML Daten" macht, hat man meiner Meinung nach
nichts gewonnen. Irgendwie abstrahiert das natürlich, aber viel
Sinn macht das nicht. Es gibt Datenbank-Systeme, die speichern
Perlcode in Feldern, das ist heisst superflexibel, weil alles
geht, ich finde das aber eher supereingeschränkt, weil nicht
wartbar.

> Aber selbst wenn man keine ORM Tools benutzt und die DB manuell
> anbindet heisst ein neues Feature manchmal auch andere
> DB-Struktur.

Mit relationalen Datenbanken kann man aber doch recht einfach
sowas wie "Vererbung" machen. Dann fügt man eine Tabelle dazu und
gut ist, meinetwegen für ein Plug-In. Geht natürlich nur, wenn
klar ist, welche Primärschlüssel etc. auch beim nächsten Update
genau so bleiben werden. Ich glaube, oft schafft es die erste
beste Implementierung in die Produktion. Später merkt man dann, das
es nicht so ideal war, und muss hier und da ändern. Das ist ganz
normale Reife, sollte sich aber nur lieber vor dem Einsatz in der
Produktion abspielen. Lieber ein Feature weniger, dafür die
anderen stabiler. Wenn man für eine Anforderung keine
überzeugende Lösungsidee hat, sollte man sie vielleicht einfach
auch mal gar nicht realisieren, anstatt irgendwas schmutziges zu
machen. Also: was nicht gut realisiert werden kann, wird gar
nicht realisiert. Das ist gut gegen Featureritis und kann zu
Nachhaltigkeit führen. Manchmal werden Sachen auch schlicht an
der falschen Stelle gemacht, weil es auf den ersten Blick
einfacher erscheint.

> Gut, man könnte aber die DB-Struktur zwar einfach stabil
> bekommen, in dem man die Tabellen "vertikal" statt "horizontal"
> baut (also eine Zeile pro Attribut, nicht eine Spalte, sowas
> wie Key-Value), aber das ist auch gruselig...

Ja, man würde die wirkliche Struktur (die Bedeutung der
erlaubten/unterstützten Key-Werten und dessen Value-Werten) nur
verstecken.

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

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.

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)?

Wie das dann nu gespeichert wird, ist da dann erstmal egal. Kann
man also vernünftig machen, egal wie komisch es die Applikation
braucht. Natürlich, wenn die Applikation Schlüsselverknüpfungen
und "Transaktionen" manuell, zu Fuss und per Hand realisiert,
weil der Programmierer sich mit Datenbanken nicht so auskannte
oder so, ist es unter Umständen schwierig, dass noch richtig
hinzukriegen, ohne die Applikation zu korrigieren (wenn die z.B.
viel mit TEMP-Tables arbeitet oder überhaupt wenn die an die
Struktur geht).

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.