Am Montag, 13. Oktober 2003 00:58 schrieb Philipp Thomas:
Jan.Trippler@t-online.de (Jan Trippler) [So, 12 Okt 2003 17:10:54 +0200]:
Stored Procedures (z. B. für schnelle, DB-interne Konvertierungen)
Wenn du auf Portabilität wenig Wert legst und wenn du der Datenbank die Arbeit überlassen willst.
Portabilität wohin? Zu einem anderen DBMS? Da kriegst Du ja schon mit Tabellen- und Spaltenbezeichnungen, Datentypen, Constraints, Primary Keys, Selects ... mehr als genug Stress (Beispiele gefällig? Versuch in Access eine Spalte namens "note" anzusprechen - nachdem Du sie erfolgreich angelegt hast wohlgemerkt, wandle Informix-Date in Oracle-Date, leg in Informix einen Tabellennamen mit mehr als 18 Zeichen an, versuch einen "outer join" oder inline-select in mysql, übertrage die Informix-Sperrgranulate auf andere DBMS, versuch generell mal Sperrstrategien zwischen verschiedenen DBMS zu portieren, kenne alle Keywords aller SQL-Dialekte - damit Du sie nicht aus Versehen als Name eines DB-Objekts verwendest, richte einen autoincrement in Oracle ein, mach einen Unload wie in Informix aus Oracle oder Access oder Interbase ...) - da macht die Anpassung von Procedures den Kohl auch nicht mehr fett. ANSI-SQL ist IMHO einer der größten Mythen dieses und des vorigen Jahrhunderts ;) BTW: Nach der Portabilität zwischen verschiedenen DBMS zu verlangen ist für mich genauso nahrhaft wie das Ansinnen, der Perl-Code der Anwendung müsse portabel zum PHP für den 2. Anwender sein. Ein DBMS ist ein Werkzeug wie eine Programmiersprache - Du fragst ja auch nicht, ob der Kunde seinen Kernel lieber in C oder in Java hätte ;) Und - ja - ich will der DB die Arbeit überlassen. DB-Design a la mysql, welches der Datenbank lediglich die Rolle eines Datengrabs zubilligt, ist für mich die schlimmste Seuche, die sich zusammen mit dem Internet ausgebreitet hat. Dann kann ich auch gleich bei C-ISAM bleiben. Wenn ich konsequent mit den Werkzeugen des DBMS arbeite habe ich: - schnellere Ausführung, da z. B. SPs, Views prekompiliert und optimiert in der DB vorliegen - einfachere Ausführung, da ich auch komplexe (in der DB-Struktur begründete) Abfragen einfach in der Anwendung implementieren kann, ohne auf zweifelhafte Mittel wie Redundanzen zurückgreifen zu müssen - automatische Erledigung von Standard-Aufgaben wie der Protokollierung von Datenänderungen oder der Verdichtung von OLTP-Daten in ein MIS-System - komfortable Realisierung komplexer Abhängigkeiten zwischen verschiedenen Daten (nicht alles lässt sich mit - ebenfalls ziemlich inkompatiblen - referentiellen Integritäten lösen) - Transparenten Zugriff auf andere Datenbanken (das Warehouse, die Adress-DB von Anbieter X, die Artikel-DB von Zulieferer Y) - nahezu vollständige Transparenz zur darüber liegenden Anwendung, ohne eine zusätzliche Schicht (Applikationsserver z. B.) dazwischen schalten zu müssen. Dann ist es nämlich egal, ob ich per PHP aus dem Web-Shop, per VPN von der Java-Anwendung des Vertreter-Notebooks per JDBC oder per C/S-Anwendung mit ODBC vom PC aus (womöglich noch mit verschiedenen OS + Programmiersprachen realisiert) auf die DB zugreife - die Funktion wird in der DB erledigt - da wo die Daten rumlungern. - mehr Schutz vor *Admins* mit gesundem Halbwissen, die mal eben per SQL dieses oder jenes Datum schnell *korrigieren* wollen. Selbst bei so einfach erscheinenden Anwendungen wie einem Web-Shop kann ich mir einen Haufen Arbeit ersparen, wenn ich mir ein DBMS suche, das die Anforderungen an die Datenstrukturen und die daraus resultierende Logik abdecken kann. Das Design der Datenhaltung ändert sich (wenn es vernünftig gestaltet wurde) nämlich deutlich seltener als die Anforderungen an die Funktionalität der GUI oder der betriebswirtschaftlichen Leistung. Eine Währungsumrechnung geht immer round(wert1 * kurs), ein rabattierter Betrag ist immer Wert * Rabatt / 100, ein Positionsbetrag ist immer Anzahl * Preis % Rabatt, ein Skonto ... Und wenn sich doch mal an Berechnungsgrundlagen etwas ändert, ist es doch immer besser, dies zentral an einer Stelle zu tun, nämlich unten in der DB. Wohlgemerkt - auch die Möglichkeiten des DBMS sind noch keine Wunderwaffe gegen komplexer werdende Anwendungen oder gar ein verkorkstes Datenmodell und sie decken natürlich längst nicht _alle_ Anforderungen an die fachlichen Funktionen von Anwendungen ab, aber sie bieten in vielen Fällen eine elegante Alternative zu ausufernden (und of langsamen) Implementierungen in der Anwendung. *schnauf* Jan