Immer wieder lese ich (nicht nur) hier, man möge das Datenbankhandling auf CRUD reduzieren...
In manchen Datenbankbüchern wiederum wird gern das umgekehrte Prinzip beschrieben...
Das eine schließt das andere nicht grundsätzlich aus und beide Vorgehensweisen haben Ihre - je nach Anwendungsfall - Berechtigung. Abgesehen davon gibt es ja auch noch Zwischenformen wenn man einen Applikationsserver dazwischenschaltet.
Die Datenbank die Arbeit machen zu lassen hat zunächst einmal den Vorteil das wenig Daten bewegt werden. Wenn ein Client lokal auf eine
DB zugreift ist das meist unwichtig, und auch in einem kleineren Netzwerk führt das nicht zu Problemen - wenn aber eine entsprechend große Anzahl an Clients über unterschiedlich schnelle (und manchmal langsame) Übertragungswege auf eine
DB zugreift kann jedes gesparte Byte zählen.
Das ist ja der Grund warum man relationalen Datenbanken meist in 3 oder höheren Normalform entwirft, um eine minimale Anzahl an Bytes zu haben die bei jeder Transaktion gelesen, geschrieben oder transportiert werden müssen.
Der zweite Grund der für eine zentralisierte Datenhaltung spricht ist die Tatsache das ein Wildwuchs an Clients die Daten nicht zwangsläufig zerstört. Zwei Clients in unterschiedlichen Versionen greifen bei einem sauberen Design dennoch definiert zu.
Einfache Skalierbarkeit und Ausfallsicherheit (beispielsweise via. Replikation) sind ein weiterer Grund für eine zentralisierte Datenhaltung.
So lange es nur um das Lesen und Schreiben von Objekten geht wiederspricht Deine im Ursprungsposting gemachte Anmerkung Objekte beispielsweise in Listen einzulesen und nur auf diesen Listen zu operieren dem nicht. Lediglich wenn die gleichen Daten von der
DB und dem Client manipuliert werden kann es einen Wiederspruch zwischen beiden Modellen geben. Aber dann kann man sich behelfen.
Nach meiner Meinung gehören Operationen die dazu dienen die Normalisierung der Datenbank sicher zu stellen und/oder die dazu dienen nur definierte Schnittstellen (Views, Funktionen, Prozeduren) anzubieten in die Datenbank, das gleiche gilt für Operationen deren Hauptzweck die Datenintegrität ist, ebenso Replikation, Logs etc, da hier von der Client nichts wissen muss.
Operationen oder Geschäftsregeln (in dem Sinne von wenn ich eine Position mit einer Menge von 5 einer Ausgangsrechnung hinzufüge dann verringert sich der Lagerbestand um 5) kann man sowohl in das Datenmodell packen wie auch in den Client. Der Client hat den Vorteil das man flexibler ist, aber eben auch mehr Mist anstellen kann. Da Du aber nach einem Schichtenmodell gefragt hast kannst Du die Schicht mit den Geschäftsmodellen auch in einen App-Server auslagern.
Mit manchem Frameworks geht das recht einfach. Im Moment bin - zumindest bei Delphi - ziemlich begeistert von TMS Aurelius. Fast alles was ich gerade eben beschrieben habe funktioniert damit sehr transparent.
cu Ha-Jö
* Ich hole mir immer das/die Objekte mit dem ich gerade arbeite (und keine anderen) über eine Abfrage. Dabei werden immer so wenig Objekte wie möglich (aber so viele wie nötig) eingelesen und die Liste wächst im Arbeitsspeicher - ändere ich ein Objekt dann wird dieses Objekt (und nur dieses) wieder zurückgeschrieben.