Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm

[jobo]

Zitat von himitsu:

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.

[jfheins]

Ich verwende liebend gerne das Entity Framework.

Im Wesentlichen baut man seine Klassen so auf, dass eine Klasse einer Tabelle in der DB entspricht. Das genaue DBMS ist dabei zweitrangig (aber nicht ganz unwichtig)
Nun hat man einen DataContext (= Datenbankschema) auf das man Abfragen durchführen kann.

Joins, Where-Einschränkungen und Spaltenauswahl wird dabei im Code definiert, die SQL wird generiert und an die Datenbank weitergereicht. Zurück kommen die Klassen, die man den Tabellen zugeordnet hat. Die Datenbank hat so viele Constraints wie sinnvoll um die Datenintegrität sicherzustellen. Also explizite Foreign-Keys und Unique Indices.

Insofern ist die Datenbank eher "dumm", weil sie keine SP und Trigger enthält, aber natürlich werden Joins in der Datenbank abgewickelt.

Beispiel:

Code:

public IQueryable<Bar> FilteredBars(int user)
{
   return from bar in Bars
         join foo in Foos on bar.ID equals foo.ID
         where foo.List == null || foo.List.Items.Any(item => item.UserID == user)
         select bar;
}