On Tuesday 22 November 2005 12:26, Felix M. Palmen wrote: > Hallo Markus, > > * Markus Schulz <[EMAIL PROTECTED]> [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
