[Diskussion] Effektivste Methode Daten aus DB ins Programm

[RWarnecke]

Hallo zusammen,

da ich gerade am planen bin, eine größere Datenbankanwendung zu schreiben, wollte ich mal fragen welche Methoden und Varianten die effektivste ist. Die Möglichkeiten kenne ich :
1.) Ich benutze derzeit für mein Programm Code-Orakel eine einfache Query. In der Query setze ich einen SQL-Befehl ab und hole mir dann über FieldByName oder Fields[x] die Daten aus der SQL-Abfrage.
Beispiel:

Delphi-Quellcode:

with Query do
begin
  SQL.Clear;
  SQL.Text := 'Select * From tabelle';
  Open;
  Active := true;
  while not eof do
  begin
    Memo1.Lines.Add(FieldByName('Name').AsString);
    Next;
  End;
  Active := false;
  Close;
end;

2.) Die Daten über Table und den DB-Komponenten (z.B. TDBEdit) zu holen und anzuzeigen. Diese finde ich aber etwas umständlich und vielleicht auch nicht ganz so flexibel wie die über die Query.
3.) Diese Möglichkeit kenne ich nur von hören sagen und zwar die Daten aus der Datenbank holen und in eine Klasse oder ein Rekord schreiben. Wenn dieses geschehen ist, die Felder (z.B Labels oder Edit-Felder) mit den Werten aus der Klasse oder dem Record füllen.

Jetzt stellen sich mir drei Fragen :
a.) Welche der drei Möglichkeiten ist die effektivste ? (Vor- und Nachteile)
b.) Wie würde die dritte Möglichkeit funktionieren und ablaufen (Ablaufplan und/oder Sourcecodebeispiel)
c.) oder gibt es noch eine andere Möglichkeit die Daten aus einer Datenbank in die Masken des Programms zu schreiben ?

[Bernhard Geyer]

Optimal ist die Verwendung von Stored Procedures die dann einfach aufgerufen wird.
Die zweitbeste Möglichkeit ist die Verwendung von prepared Statements:

Delphi-Quellcode:

myQuery.SQL.Add('INSERT INTO MyTABLE(Feld1, Feld2) VALUES(:Feld1, :Feld2)');
myQuery.Prepare;
for i := 0 to Datensatzcount
begin
  myquery.ParamByName('Feld1').AsString := Datensatz[i].Feld1;
  myquery.ParamByName('Feld2').AsString := Datensatz[i].Feld2;
  myquery.ExecSQL;
end;
myQuery.UnPrepare;

Syntax (Methodennamen) unterscheiden sich je nach verwendeter nativer Zugriffskomponente etwas.

[spaxxn]

Nur mal eine Frage:

Wieso steht eine Klasse zu erstellen überhaupt in der Auswahl?

[RWarnecke]

Zitat:

Zitat von spaxxn

Nur mal eine Frage: Wieso steht eine Klasse zu erstellen überhaupt in der Auswahl?

Diese Variante kenne ich nur vom hören sagen. Ich kann mir vorstellen, dass ich da eine Trennung zwischen GUI und eigentlichen Programmcode besser realisieren kann.

[chaosben]

Die Nutzung einer Business/Daten-Logik (also Trennung von Daten und GUI) ist für den Entwickler sehr angenehm.
Ich will jetzt nicht die vielen Vorteile aufzählen, weil du nach der Effektivität gefragt hast: Wenn du so eine Zwischenschicht einziehst, leidet die Performance. Nicht viel; eben je nach Implementation.
Die Frage ist: Bist du auf Effektivität angewiesen oder kannst du eine wenig Verlust in Kauf nehmen? Wenn ja dann bau dir unbedingt so eine Logik-Schicht dazwischen. Wenn du später mal was ändern/hinzufügen willst, freust du dir ein 2. Loch in den Hintern weil es so einfach geht. (Das ist meine Erfahrung.)

[QuickAndDirty]

Ja, ein Layer für die Persistenz ist angenehm wenn man es hat, und viel arbeit es nach zu rüsten.
Dann wäre es noch sinnvoll die Datenzugriffskomponenten nicht direkt zu verwenden sondern
den Umweg über eine Fassade zu gehen. Das macht den Code auch dann noch leicht pflegbar wenn sich die
Funktionalität der Komponenten ändern oder sogar andere Komponenten genutzt werden müssen. Immer unter der
Vorraussetzung das man auf so proprietären Unfug wie Stored Procedures verzichtet.

Wenn es allerdings um reine Performance geht sind Stored Procedures die erste Wahl...
...du musst dir halt nur die Arbeit auf jedem SQL-Server von neuem machen.

[RWarnecke]

Zitat:

Zitat von chaosben

Die Nutzung einer Business/Daten-Logik (also Trennung von Daten und GUI) ist für den Entwickler sehr angenehm.
Ich will jetzt nicht die vielen Vorteile aufzählen, weil du nach der Effektivität gefragt hast: Wenn du so eine Zwischenschicht einziehst, leidet die Performance. Nicht viel; eben je nach Implementation.
Die Frage ist: Bist du auf Effektivität angewiesen oder kannst du eine wenig Verlust in Kauf nehmen? Wenn ja dann bau dir unbedingt so eine Logik-Schicht dazwischen. Wenn du später mal was ändern/hinzufügen willst, freust du dir ein 2. Loch in den Hintern weil es so einfach geht. (Das ist meine Erfahrung.)

Effektivität bedeutet für mich, dass ich am Anfang vielleicht etwas mehr Arbeit habe um dann später bei der Wartung, Pflege u.s.w. Arbeit einsparen kann. Ich hatte mir schon überlegt eine Trennung zwischen Daten und GUI zu machen, nur leider fehlt mir da der Ansatz für die Umsetzung. ich hätte gerne eine gesunde Mischung zwischen einer performanten und effektiven Anwendung. Dazu bin ich auch gerne bereit, gewisse Performanceeinbussen hinzunehmen, wenn ich später bei einer Änderung oder Erweiterung dafür weniger aufwand habe.

Da ich auch mit dem Gedanken spiele es für mehrere Datenbanksysteme das Programm zu Verfügung zu stellen würde sich ja die Trennung von Daten und GUI anbieten. Wie seht Ihr das ? Was habt Ihr dazu für eine Meinung ?

Wie könnte denn ein Aufbau einer Business/Daten-Logik aussehen ? Benutze ich dafür Records, Klassen oder Arrays oder was ?

[nahpets]

Zitat:

Zitat von RWarnecke

Zitat:

Zitat von spaxxn

Nur mal eine Frage: Wieso steht eine Klasse zu erstellen überhaupt in der Auswahl?

Diese Variante kenne ich nur vom hören sagen. Ich kann mir vorstellen, dass ich da eine Trennung zwischen GUI und eigentlichen Programmcode besser realisieren kann.

Wir haben bei einem Projekt (nicht mit Delphi) Methoden, die dynamisch aus den Datenbanktabellen entsprechende Zugriffklassen erstellen, die das Lesen, Speichern (Insert und Update), sowie das Löschen übernehmen. Änderungen an der Datenbank führen automatisch zur Anpassung der Zugriffklassen. Abhängigkeiten zwischen Tabellen (1:n-Beziehungen) werden berücksichtigt, so dass z. B. eine Änderung des Schlüssels des Mastersatzes auch die Detailsätze berücksichtigt werden. Als Entwickler der Clientsoftware muss man sich hier quasi um nichts kümmern.
Das Einzige was der Anwendungsentwickler machen muss ist zwei Methoden implementieren, die die schönen Namen ObjektInMaske und MaskeInObjekt heißen. Die Namen dürften selbsterklärend sein.

Vor längerer Zeit habe ich mal versucht, sowas in Delphi zu realisieren. Es geht (weitgehend), ist aber aus Zeitgründen nie bis zur "Serienreife" gekommen.

Zitat:

Zitat von chaosben

freust du dir ein 2. Loch in den Hintern weil es so einfach geht.

Da ist was dran, einmal ein bisserl mehr Arbeit machen und später sehr viel Arbeit sparen.

[guidok]

[quote="RWarnecke"]

Zitat:

Zitat von chaosben

Da ich auch mit dem Gedanken spiele es für mehrere Datenbanksysteme das Programm zu Verfügung zu stellen würde sich ja die Trennung von Daten und GUI anbieten. Wie seht Ihr das ? Was habt Ihr dazu für eine Meinung ?

Wie könnte denn ein Aufbau einer Business/Daten-Logik aussehen ? Benutze ich dafür Records, Klassen oder Arrays oder was ?

Da ich selbst auch schon diese
Frage gestellt habe, schau doch da mal nach.

Ich habe die dort erwähnte Möglichkeit (Post #11) für mich vereinfacht und versuche nun auf dieser Basis etwas zustande zu bekommen.

[RWarnecke]

Zitat:

Zitat von guidok

Da ich selbst auch schon diese
Frage gestellt habe, schau doch da mal nach.

Ich habe die dort erwähnte Möglichkeit (Post #11) für mich vereinfacht und versuche nun auf dieser Basis etwas zustande zu bekommen.

Danke für den Link, werde ich mir heute Abend zu gemüte ziehen.

[RWarnecke]

Ich habe mir die Links angeschaut. Vom theoretisch Teil her, habe ich es soweit verstanden. Nur mir fehlt ein Ansatz, wie ich das OPF umsetzen soll. Eine meiner ersten Ideen war es, Klassen zu schreiben für die unterschiedlichen Bereiche, welche mir die Daten aus der Datenbank zur Verfügung stellen, was ich aber für etwas umständlich halte. Deshalb brauche ich da von euch mal ein paar Denkanstöße, wie ich so ein OPF in Programmcode umsetzen kann.

[guidok]

Hallo Rolf,

ich sehe jetzt zwei Möglichkeiten: Entweder du programmierst dir das grundlegende Framework selbst und erstellst auf dieser Basis deine benötigten Business Objects oder du verwendest eine bereits fertige Lösung (siehe letztes Post) und implementierst darauf deine BO's.

Bei der zweiten Lösung hast du zwar weniger Hintergrundwissen, was im OPF passiert, du wirst allerdings schneller zu einer funktionstüchtigen Anwendung kommen und kannst davon ausgehen, dass das OPF fehlerfrei ist (wenigstens weitgehend).

Ansonsten sollte alles klar sein. Du musst zunächst die Business Objects erstellen (z.B. BO Kunden für Kundenstammdaten), welche dir die benötigten Daten (und entsprechende Logik) für deine GUI oder Reports bereitstellen.

Guido

[hanspeter]

Hallo,

ich verwende für solche Aufgaben IBDAC.
Das gibt es als Unidac auch für mehrere Datenbanken.
In diesem Framework setzt eine Query auf einem Memorydataset auf.
Die Query hat einen Disconnect Mode. D.h. Daten werden nach dem Einlesen persisistent im Speicher gehalten und
Updates/Inserts im Cache gehalten.

Also folgender Ablauf:

Connect
Lese Datensatz
Disconnect

Den Datensatz bearbeiten.

Dann Abfrage ob Update/Insert notwendig ist.
Wenn ja dann

Connect
ApplyUpdates
Disconnect

Diese Lösung hat den Vorteil, das ich im Programm mit datensensitiven Componenten arbeiten kann.

Datenmengen stelle ich in einem Grid dar, welches sich aus einer Query selbst initialisiert und dann die
Auswahl ohne Datenbankverbindung darstellt.
Das Grid handelt das Read/Update selbst.
Objecte wie z.B. KundenClass oder ArtikelClass melden sich bei der Datenbankschicht an (Observer) und werden dann
bei Änderungen automatisch gefüllt.
An diesem Teil arbeite ich im Moment noch.


Gruß
Peter

[Sherlock]

Ich verwende keine TTables, die seien inperformant habe ich mir mal sagen lassen. Die klassische Kombination aus TDataSet und TDataSource tun ihren Dienst bei Datengebundenen Komponenten, und für die eine oder andere Abfrage zwischendurch gibts TQuerys. Ist kein Hexenwerk, kein Vorbild an OOP, aber es läuft, und es läuft schnell.

Für mich haben Zwischenschichten das Problem, daß sie zwar hübsch modern sind, aber wenn man etwas dran tun muß, das über Optimierung hinausgeht dann muss man das in der Regel in allen Schichten gleichzeitig tätig werden.

Just my 2 cents.

Sherlock

[RWarnecke]

Zitat:

Zitat von guidok

ich sehe jetzt zwei Möglichkeiten: Entweder du programmierst dir das grundlegende Framework selbst und erstellst auf dieser Basis deine benötigten Business Objects oder du verwendest eine bereits fertige Lösung (siehe letztes Post) und implementierst darauf deine BO's.

Bei der zweiten Lösung hast du zwar weniger Hintergrundwissen, was im OPF passiert, du wirst allerdings schneller zu einer funktionstüchtigen Anwendung kommen und kannst davon ausgehen, dass das OPF fehlerfrei ist (wenigstens weitgehend).

Wenn möchte ich schon wissen, was mein OPF macht. Dazu hatte ich den Gedanken, dass ich alles in einem Datenmodul packe und diese Unit halt immer dann einbinde, wenn ich den Zugriff auf die Datenbank brauche. In dem Datenbankmodul sind dann alle Funktionen für die verschiedensten Abfragen/Insert/Updates vorhanden. Ich erreiche damit aber auch kein richtiges OPF oder sehe ich das falsch ?

Zitat:

Zitat von guidok

Ansonsten sollte alles klar sein. Du musst zunächst die Business Objects erstellen (z.B. BO Kunden für Kundenstammdaten), welche dir die benötigten Daten (und entsprechende Logik) für deine GUI oder Reports bereitstellen.

Das ist schon mal ein guter Hinweis, denn ich zerbreche mir gerade den Kopf darüber, wie und wann ich etwas erstelle.

Mein Ziel ist es eine gesunde Mischung zwischen einer effektiven Anwendung und einer einfachen wartbaren Anwendung zu finden. Das heißt für mich, ich brauche auf jedenfall ein OPF.

[DeddyH]

Hallo Rolf,

im Moment hab ich nicht soviel Zeit, aber ich könnte heute Nachmittag einmal meine Gedanken zum Aufbau so einer Anwendung posten, das dürfte aber ein längerer Post werden :mrgreen:

[guidok]

Ich habe gerade noch etwas gefunden. Bin mit dem Durchlesen noch nicht fertig, aber könnte interessant sein...

[DeddyH]

So, wie angedroht hier einmal die Gedanken, die ich mir gemacht hatte. Was ich letztendlich erreichen wollte war, dass das Frontend mit "ganz normalen" Klassen hantiert und nichts von der DB weiß bzw. wissen muss. Ein "fertiges" OPF wollte ich allerdings nicht benutzen, da diese entweder zu unflexibel oder zu kompliziert sind und ich außerdem die Kontrolle behalten wollte.
Fangen wir mal "unten" (bei der Datenbank) an. Nach einem größeren Kraftakt resultierend aus einer DB-Umstellung bin ich auf den Trichter gekommen, zur Kommunikation zwischen OPF und DB ausschließlich auf Views und SPs zurückzugreifen. Man kann das auch dahingehend auf die Spitze treiben, dass man alle Rechte auf die Tabellen entzieht und nur diesen Views und SPs erteilt. Nehmen wir als Beispiel einmal an, wir möchten Personen mit ihrer Augenfarbe (eigene Stammdatentabelle) erfassen. Dann könnte die View beispielsweise so aussehen (schnell aus dem Kopf getippt, keine Garantie für Funktion):

SQL-Code:

CREATE VIEW VW_Person(ID,Name,Vorname,AugenfarbenID,Augenfarbe)
AS
  SELECT
    Person.ID AS ID, 
    Person.Name AS Name, 
    Person.Vorname AS Vorname, 
    Augenfarben.ID AS AugenfarbenID,
    Augenfarben.Bezeichnung AS Augenfarbe
  FROM
    Person
  JOIN 
    Augenfarben ON Person.Augenfarben_ID = Augenfarben.ID

Dazu kommen dann noch 3 SPs (je eine zum Einfügen, Ändern und Löschen). Die entsprechende Klasse im OPF hätte dann die entsprechenden Properties, die aus der View gefüllt und mittels SP geändert werden. Zusätzlich habe ich noch Objektlisten implementiert, um z.B. eine Auswahl per ComboBox zu ermöglichen.

Delphi-Quellcode:

TPersonenliste.GetPersonen(const sList: TStrings);

Dabei werden die entsprechenden Objekte mittels AddObject sofort in den Items hinterlegt (kann man auch anders machen, wenn man den Speicher schonen will oder voraussichtlich sehr viele Datensätze erwartet). Nun ist es am Frontend relativ leicht, einen Datensatz zu holen und zu bearbeiten: aus den Items z.B. einer ComboBox den entsprechenden Satz auswählen, in die Detailansicht wechseln, bearbeiten und abspeichern. Die SPs, die dahinterstehen, müssen mich hier überhaupt nicht mehr interessieren, wenn sie einmal ordentlich durchgetestet sind.

So mache ich das im Moment (ist ja immer noch in der Entwicklung), ob das der Königsweg ist, kann ich nicht entscheiden, aber es funktioniert bislang überraschend gut ;)

[guidok]

@DeddyH:

Der größte Nachteil den ich sehe ist, dass du durch die Views und SP sehr dicht an der DB arbeitest. Ein Wechsel der DB oder das Speichern z.B. in XML wird damit sehr schwierig...

Ich weiß aus eigener leidvoller Erfahrung, dass was in MSSQL funktioniert, in MySQL völlig anders ist.

[DeddyH]

Das gebe ich zu, ist aber auch nicht vorgesehen.

[RWarnecke]

Zitat:

Zitat von guidok

Ich habe gerade noch etwas gefunden. Bin mit dem Durchlesen noch nicht fertig, aber könnte interessant sein...

Was ich so aus diesem Tutorial rauslese ist ja, dass die einfachste Methode über ein TDataSet ist, wenn ich selber soetwas erstellen will. Desweiteren stört mich, dass in dem Tutorial über TDBEdit Felder gegangen wird. Ich persönlich hasse diese Komponenten, ich bin bis heute nie damit richtig zurecht gekommen. Ich tendiere immer mehr dazu, dass in einer ähnlichen Art wie Detlef zu machen.
Ich habe ein Datenbankmodul, wo die TIBQuery, TDataSource und die anderen Komponenten für die Datenbankverbindung drinstehen. Beim Initialisieren des Datenbankmoduls wird die Verbindung zur Datenbank hergestellt. Dazu kommen in das Modul noch die ganzen Funktionen/Proceduren für die Abfragen, die ich sonst im Sourcecode der Anwendung untergebracht hatte. Das heißt, ich rufe die Proceduren/Funktionen aus dem Modul direkt aus dem Sourcecode der Hauptanwendung auf und übergebe die Werte der Form an die Funktion/Procedure.
Den Vorteil darin sehe ich, ich habe eine eigene Unit/Modul welches alle Aufgaben der Datenbank erledigt. Bei einer eventuellen Umstellung der Datenbankkomponenten müsste ich nur diese eine Unit anfassen, was natürlich von Vorteil wäre. Mir ist auch klar, dass das kein reines OPF ist. Aber es wäre eventuell eine alternative. Was meint Ihr dazu ?

Das ganze könnte man ja dann noch weiter ausbauen und sich damit eine eigene DLL basteln, die mehrere Datenbanken unterstützt. Das sind erstmal meine Gedanken dazu.

[alzaimar]

Zitat:

Zitat von guidok

Der größte Nachteil den ich sehe ist, dass du durch die Views und SP sehr dicht an der DB arbeitest. Ein Wechsel der DB oder das Speichern z.B. in XML wird damit sehr schwierig...

Ich weiß aus eigener leidvoller Erfahrung, dass was in MSSQL funktioniert, in MySQL völlig anders ist.

Das kann ich nicht nachvollziehen. Durch vollständige Kapselung der Datenbank-Perversionen erreiche ich doch gerade eine Datenbankunabhängigkeit. Nun gut, die neue Datenbank muss zumindest die Grundzüge eines SQL-RDBMS (aka Views und Stored Procedures) beherrschen. Da fällt MySQL natürlich runter. So wie Access und DBase auch. :stupid:

[nahpets]

Hallo,

Zitat:

Zitat von guidok

Der größte Nachteil den ich sehe ist, dass du durch die Views und SP sehr dicht an der DB arbeitest. Ein Wechsel der DB oder das Speichern z.B. in XML wird damit sehr schwierig...

Ich weiß aus eigener leidvoller Erfahrung, dass was in MSSQL funktioniert, in MySQL völlig anders ist.

dachte, dass sei der Vorteil, Programmlogik wird von Datenbanklogik getrennt.
Je nach Datenbank sehen die dort implementierten Teile (im schlimmsten Fall) sehr unterschiedlich aus, aber am Programm muss nichts geändert werden. Von z. B. MSSQL solltes Du so ohne Programmänderungen nach Oracle kommen, auch wenn die SQL-Dialekte doch einige (nicht unerhebliche) Unterschiede aufweisen. Und bei den SP's dürften die Unterschiede schon gigantisch sein. Aber Dein Programm sollte da nicht kratzen.

[DeddyH]

Eben deswegen hatte ich mich ja auch dafür entschieden, soviel Funktionalität wie möglich in die DB statt ins OPF zu verlagern.

[khh]

Zitat:

Zitat von DeddyH

Eben deswegen hatte ich mich ja auch dafür entschieden, soviel Funktionalität wie möglich in die DB statt ins OPF zu verlagern.

hat wohl beides Vor- und Nachteile.


ich denke, wenn die DB gewechselt wird müssen die SP neu erstellt werden.
Also kann ich die Statements auch im Programm anpassen bzw. austauschen.

Ist die "theoretische" Kapselung der Funktionalität so ein Vorteil?

Oder gibts ne Möglichkeit die SP und Views zwischen den RDBMS auszutauschen?

Gruss KH

[RWarnecke]

Zitat:

Zitat von khh

Ist die "theoretische" Kapselung der Funktionalität so ein Vorteil?

Oder gibts ne Möglichkeit die SP und Views zwischen den RDBMS auszutauschen?

Gruss KH

Ich finde schon, dass ich im weiteren Verlauf dadurch schon mehr Vorteile habe. Den einzigsten größten Nachteil, der mir im Moment auffällt ist der, wenn ich sehr viel Funktionalität in die DB packe. Da bin ich wiederum nur auf RDBMS angewiesen, die SP und Views unterstützen. Wenn ich jetzt das ganze in einer Unit in Delphi mache, bin ich da unabhängiger von der Datenbank.

[nahpets]

Hallo,

Zitat:

Zitat von khh

ich denke, wenn die DB gewechselt wird müssen die SP neu erstellt werden.

Ja, aber auch nur die.

Zitat:

Zitat von khh

Also kann ich die Statements auch im Programm anpassen bzw. austauschen.

50 Kunden und 10 unterschiedliche Datenbanken und davon noch jeweils 5 unterschiedliche Versionen.
Und nu?

Zitat:

Zitat von khh

Ist die "theoretische" Kapselung der Funktionalität so ein Vorteil?

Die theoretische nicht, aber die praktische.

Zitat:

Zitat von khh

Oder gibts ne Möglichkeit die SP und Views zwischen den RDBMS auszutauschen?

Die Rechnung hast Du dann ohne die Datenbankhersteller gemacht.
Stell' SQLs für Massendatenverarbeitung, die für Oracle optimiert sind, um auf MS-SQL, MySQL, Firebird, Postgres, Ingres...
ff oder Fiel Fergnügen, wie man bei uns im Rheinland sagt :wink:

[mkinzler]

Zitat:

Stell' SQLs für Massendatenverarbeitung, die für Oracle optimiert sind, um auf MS-SQL, MySQL, Firebird, Postgres, Ingres...

Für FireBird könnte man sich dann Fyracle anschauen.

Aber ich bin auch die Meinung das die Kapselung wenn möglich ins DBMS gehören ( SPs). So entlastet man auch den Client und vereinfacht das Deployment/Update der Anwendung

[khh]

Zitat:

Zitat von mkinzler

Zitat:

Stell' SQLs für Massendatenverarbeitung, die für Oracle optimiert sind, um auf MS-SQL, MySQL, Firebird, Postgres, Ingres...

Für FireBird könnte man sich dann Fyracle anschauen.

Aber ich bin auch die Meinung das die Kapselung wenn möglich ins DBMS gehören ( SPs). So entlastet man auch den Client und vereinfacht das Deployment/Update der Anwendung

unter diesem Aspekt, gebe ich euch Recht.

Was aber, wenn ich selbst entscheide mit welchem RDBMS ich meine Anwendungen erstelle und verkaufe?
Und dabei bleibe ich bei einem RDBMS.


Wo ist dann noch der gepriesene Vorteil ?

Gruss Kh

[mkinzler]

Du kannst nachträglich die Struktur der Datenbank ändern ohne das Programm anfassen zu müssen

[nahpets]

Hallo,

an was für Anwendungen denkst Du?

Ein Abrechnungssystem mit sagen wir 50 Tabellen mit insgesamt sowas um die 200 Millionen Datensätzen.
Du musst aus den Tabellen Daten selektieren, summieren und in die Tabellen zurückschreiben. Die Summierregeln sind so, dass sie mit einem einfachen Update und den üblichen Rechenoperationen nicht möglich sind.

Deshalb musst Du wohl oder übel die 200 Millionen Datensätze mehr oder weniger häufig anpacken, lesen, schreiben...
Also rein ins Programm, raus aus dem Programm.
Die Rechenoperation könntest Du aber auch z. B. mit PL-SQL machen (weil wir uns halt für Oracle entschieden haben).
Was meinst Du, wer gewinnt, wenn's um korrektes Ergebnis und Geschwindigkeit geht?

Meine Regel ist da ganz banal: Lass alles das die Datenbank machen, was sie besser kann.

Und im Zugriff auf die Daten ist sie besser, sie hat die Daten schon und muss sie nicht erst von jemand anderem anfordern, über mehr oder weniger schnelle Leitungen hin- und hertransportieren, kann sich die Daten selbst zugriffsoptimiert zurechtlegen...

Warum soll ich mir in meinen Programmen darüber einen Kopp machen, da akzeptiere ich gerne den (vermeintlichen?) Verwaltungsoverhead in meinen Programmen für die Trennung.

Irgendwann braucht jede Datenbank mal 'nen neuen Server oder ein Update..., da packst Du nur die Datenbank an.
Und selbst, wenn Du ein Programm an eine Datenbank koppelst, kannst Du ausschließen, dass einzelne Kunden nicht eventuell eine etwas andere Datenbankversion haben als andere, Versionswechsel, gleiche Datenbank, aber anderes Betriebssystem...
Brauchen alle Kunden die gleichen Auswertungen oder gibt es da eventuell die Möglichkeit zur Konfiguration...

[khh]

diese Argumente überzeugen.


Gruss Kh