Immer wieder lese ich (nicht nur) hier, man möge das Datenbankhandling auf CRUD reduzieren und ansonsten alle Zugriffe programmgesteuert vornehmen:
- Daten in Listen/Objekte einlesen
- Daten in/mit diesen Objekten bearbeiten
- geänderte/neue Daten aus den Objekten wieder in der
DB speichern
- direkte
DB-Zugriffe (z.B. über datensensitive Steuerelemente) sind verboten
d.h. die ganze Datenbank in unteren Schichten verstecken und nur mit Objekten arbeiten. Die Datenbank ist nur Mittel zum Zweck, um Objekte zu persistieren. Damit wäre die verwendete Datenbank auch relativ egal, weil man eh mit dem kleinstmöglichen
SQL-Subset arbeitet. Puristen verzichten sogar auf JOINs und machen auch das in der Anwendung.
Das wäre dann das Prinzip der dummen Datenbank mit dem schlauen Programm.
In manchen Datenbankbüchern wiederum wird gern das umgekehrte Prinzip beschrieben: fast die ganze Programmlogik findet sich in Views, Stored Procedures, Stored Functions und Triggern. Man ist dann natürlich abhängig von der verwendeten Datenbank. Auf Anwendungsseite ist der Zugriff flexibel, es könnten sogar datensensitive Steuerelemente herhalten, denn die Views und Trigger abstrahieren die normalisierte Tabellenstruktur einfach weg. Zudem kann ein passendes Rechtekonzept den Zugriff "am View vorbei" verbieten, so dass sämtliche Anwendungsprogramme die gleichen Zugriffe bekommen.
Das wäre dann die schlaue Datenbank mit dem dummen Programm.
In der Praxis hat man vermutlich immer eine Mischung von beidem, aber je nach Anwendungsfall ist die eine oder andere Ausrichtung stärker vertreten.
Wie ist das bei euch so?