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

[Steffen Dettmer]

Hi,

ich mach mal ein reply auf'n ganz altes Posting :)

* Rocco Rutte wrote on Thu, Jul 31, 2008 at 15:35 +0200:
> * 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.

  (`DB-Storage' klingt für mich nicht so gut, als ob man
   eigentlich ein Filesystem möchte, aber eine DB nimmt, weil man
   da 3 Zeilen Code spart oder weil im Linuxmagazin gerade ein
   Datenbankartikel war...)

Ja, DB-Struktur stabilisieren und Anwendungen drauf, klar. Die
Abstraktion sollte sich dabei natürlich (im Sinne von
`von selbst in natürlicher Art und Weise') ergeben. Es sollte
auch umgekehrt gehen, fällt scheinbar aber oft schwerer.

> >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... :)

Ja, eben! Viele denken scheinbar ausschliesslich in irgendwelchen
imperativen Programmiersprachen (C, C++, Java, PHP, Perl, ...),
und in 3GL (iterationen von Elementen einer Menge etc) und kaum
in (aus Datensicht) höhreren Sprachen wie SQL (4GL). Natürlich
kann man in einer 3GL Sprache z.B. Mengenoperationen über
Funktionen und Listen `emulieren', aber das ist dann nicht so
leicht generisch zu realisieren und in den Implementierungen wird
dann irgendwas iteriert. Wenn dabei `für jedes Element tue X' in
der Iteration durchgeführt wird, ist es (aus 4GL Sicht) schon
falsch. Das ist nämlich eine (1) Operation und erfordert damit
auch nur eine Anweisung.

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

Eigentlich sollte ja SQL von der DB abstrahieren, wie C vom
Compiler abstrahieren sollte. Schade, dass man das nicht
geschafft hat.
Wenn man 3GL 1:1 auf 4GL mappt, muss nicht unbedingt was
effizientes dabei rauskommen (denn man kann ja z.B. im
Extremfall die ganzen Objekte holen und im Client lokal suchen,
funktioniert ca solange, bis man es benutzen will und Daten hat -
hab ich in der Praxis schon gesehen sowas).

Aber vielleicht funktioniert das ja über irgendwelche Magien gut.
Aber dazu müsste der Generator wissen, welche höheren Operationen
es gibt, oder?

> 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.

Natürlich lässt sich jede Logik automatisch durchtesten
(wenn sie ein endlicher Automat ist). Ob die Designs einer
durchschnittlichen Web 2.0-Anwendung das hergiben, ist sicherlich
ein anderes Thema (ich würde raten, dass die Antwort hier das
Gegenteil ist, sich also nicht automatisch testen lässt, weil
falsch designed).

Jedenfalls sind Objekte nur 3GL, Entitäten und keine Mengen. Rein
logisch muss das doch hinken, wenn man Mengen 1:1 auf Entitäten
mappen will? Und wenn man 1:1 mappt, warum kann man dann nicht
einfach die Instanzen serialisieren und speichern? Müsste in Java
doch auch ziemlich automatisch gehen.

> ...also nimmt man ORM. Das würde ich übrigens auch tun... :)
> Bei Performance-kritischen Sachen fällt ORM eh aus.

Für Performance nimmt man doch Datenbanken? Die sind in kleinen
Testmengen vielleicht langsam, skalieren aber gut, sind also bei
vielen Daten und grossen Mengen auch nicht viel langsamer, also
performant. Das ist ja ein Vorteil von 4GL. Egal wie gross die
Menge, eine Anweisung ist eine Anweisung (klar, dass sie evtl.
bissel länger dauert etc) und sie kann auch noch optimiert
werden.

> >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. 

Für 0815 und Web 2.0 Tageshacks braucht man überhaupt keine
Datenbank, oder? Wenn der Aufwand für 20 Zeilen SP lieber durch
200 Zeilen unsicheres, langsames Java `gespart' wird, hat manja
auch nix gewonnen. Aber CMS und sowas sind doch keine 0815
Teile sondern teuere Poweranwendungen, die essentielle Rollen bei
Prozessen spielen und damit verfügbar sein und gewartet werden
müssen etc. - oder?

> Vor allem weil sich Dialekte oft an sehr subtilen Stellen
> unterscheiden, d.h. der gemeinsame Codeanteil ist sehr hoch.

Basisklassen verwenden? Sourcecode-Generierung?

> Das wäre wartungsmäßig Horror für mich.

Ich find es immer Klasse, wenn man Code wiederverwenden kann ;)

Nee, mal im Ernst, was meinst Du damit?

> 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. 

Ach echt? Es gibt richtige DBMSes, wo views r/o sind? Das ist
natürlich extrem doof. Damit fehlt doch eine ganze Dimension der
Abstraktion (oft auch wichtig, um neue und alte Versionen
nebeneinander laufen zu lassen). Was heisst das denn, dass man
wirklich eine Tabelle haben muss, wenn man was ändern (update)
will? Kann man sich doch kaum vorstellen, wie soll man denn damit
arbeiten, muss doch schonmal jemand gemerkt haben!

> Ansonsten müsste man das über Tabellen und Trigger vermutlich
> simulieren, aber...  

Sachen, die in Sprachen oder Systemen logisch fehlen, sind oft
sehr schwer und nur umständlich zu simulieren (Klassen in C oder
Views in solchen DBMSes). In dem Fall müsste man zum Lesen und
zum Schreiben verschiedenes benutzen (views zum Lesen,
spezial-Tabelle ohne Inhalt zum Schreiben), was vermutlich nicht
so einfach geht (wie wird gelockt etc).

oki,

Steffen

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