Re: LAPP statt LAMP?
On Tuesday 22 November 2005 12:26, Felix M. Palmen wrote:
> Hallo Markus,
>
> * Markus Schulz <msc@antzsystem.de> [20051122 12:18]:
> > Versteh ich nioht, wieso wird die Applikation durch Verwendung von
> > Trigger und SP auseinandergerissen?
>
> Ein "zip hier, unzip dort" funktioniert nicht mehr. Es sei denn man
> macht sich die zusätzliche Mühe und schreibt ein sehr umfassendes
> "Setup-Script".
Das hat man bei Datenbank gestützten Applikationen doch nie. Eine
ordentliche Setup-Engine sollte man dafür schon entwickeln. Dabei kann
man gleich den Update-Mechanismus mit entwickeln, den man früher oder
später eh brauchen wird.
> > Warum das ganze dann noch Einfluss auf einen
> > Serverumzug hat versteh ich auch nicht. Wir haben in den letzten
> > Jahren keine derartigen Probleme mit Postgres gehabt. Oder verstehe
> > ich dich hier irgendwie falsch?
>
> Man ist zumindest sehr von der Qualität der Im- und Export Funktionen
> des DBMS abhängig. Bei MSSQL habe ich da nicht gerade erfreuliche
> Erfahrungen.
Wir hier mit Postgres haben da bisher kaum Probleme. Wir setzen das
alles aber auch mittels Debian Paketen um. Dank Transaktionen bei
Postgres hat man bei Problemen im Update Vorgang auch keine
Inkonsistenz.
> > Gerade SP erlauben es viele Arbeiten die mit der Oberfläche nichts
> > zu tun haben in die Datenbank auszulagern und bereinigen damit den
> > Oberflächen Code.
>
> Viel eleganter wäre es, dafür eine weitere Schicht in seiner eigenen
> Applikation zu haben. (Die wäre dann auch der richtige Angriffspunkt
> bei einem Wechsel des DBMS).
Da hast du recht, eine weitere Schicht vor der Applikation ist sehr
sinnvoll. In dieser Schicht entscheide ich dann, ob ich die von der
Anwendung angeforderte Datenbank Funktion als SP Aufruf weiterreiche
oder direkt als hinterlegten SQL Code ausführe muss, weil die DB keine
SP bietet. Wieso also auf Features verzichten die ich nutzen kann?
Einzig ordentlich designen muss man das ganze.
> > > zum größeren Problem wird, an einen Austausch des DBMS möchte ich
> > > gar nicht erst denken.
> >
> > 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.
>
> Ein Faktor für Skalierbarkeit ist unter anderem der möglichst
> einfache Austausch von Modulen.
Da magst du Recht haben, trotzdem wird es immer mit Arbeit verbunden
sein. Ich glaube kaum das es Enterprise Lösungen gibt, die nur durch
Installation eines anderen DBMS und Import des SQL92 Dumps lauffähig
werden. Falls doch erscheint mir das DBMS dort nicht als zentraler
Bestandteil der Lösung.
Markus
--
Kreuzigt mich - aber Debian ist einfach deppensicher.
Es lässt Deppen gegen eine Wand von Schwierigkeiten klatschen und
langsam abtropfen. Wer die Tür findet, darf mitspielen - und so sieht
das Spielzeug dann eben aus: Gut gepflegt. -- Joerg Rossdeutscher
Reply to: