Was man gegen die Logik in der
DB sagen kann, ist das Debuggen des Programms.
Gut, es ist zwar bei vielen
DBMS auch möglich das zu machen, aber "zusammen" mit dem Programm dann halt nicht, alles in einem Debugger.
Zitat:
Das kann man mit
DB-Mitteln nicht realisieren.
Das geht schon, denn viele
DBMS bieten es an, dass man Fremdfunktionen einbinden kann.
Da wird eure Funktion dann wir eine normale SP aufgerufen, bzw. wie die BuildIn-Funktionen ala TRIM oder COALESCE.
Ihr schreibt eine
DLL z.B. mit Delphi, veröffentlicht eure Funktionen (Exports) und bindet das dann ins
DBMS ein.
Debuggen kann ich auch die SP, wenn es von den Tools unterstützt wird. Freilich kenne ich auch keins, das es durchgängig macht (Clientcode plus SP).
Aber: ich kann in
SQL ellenlange Testscripts schreiben, SP aufrufen bis der Arzt kommt, inkl. Prüfviews usw. und wenn das Ergebnis falsch ist, sag ich rollback und korrigiere die SP oder den View.
Auf diese Weise kann ich tatsächlich komplette Business Prozesse abbilden. Daher ist mir das "Unittesting" Argument auch nicht so klar.
Was komplexe Anwendungen angeht, OCR, Thesaurus und Co, da kann ich nur empfehlen, sich mal die Leistungsfähigkeit führende
DB Anbieter plus Erweiterungen anzusehen.
SEPA
XML mache ich per
SQL, Excel lese ich per SP.
Und falls ich es noch nirgendwo erwähnt hatte
PostgreSQL finde ich ist ein Spitzensystem. Dafür würde ich sogar Geld ausgeben, aber es ist leider kostenlos.
PostgreSQL ist im Übrigen auch ein gutes Argument gegen das "Du kannst nicht wechseln". Ich schätze, dass man eine Mehrheit von Oracle Systemen durch PG ersetzen kann, mit überschaubarem, also kalkulierbaren Aufwand und vertretbaren Kosten. Ähnlich sieht es vielleicht bei anderen Systemen aus.
Es gibt sehr abgefahrene Features in manchen
DB, Systeme wie von Oracle müssen sich ja irgendwodurch auszeichnen und all das Schmerzensgeld rechtfertigen, z.B. sowas wie Multitenancy, Versionierung von Logik oder andere Sachen. Aber in der Praxis habe ich davon noch nichts eingesetzt.