"(Client)Programm dumm + (Server)
DB schlau" contra "(Client)Programm schlau + (Server)
DB dumm" ... da gibt es doch noch was... die Multi-Tier-Architektur:
- die (Server)
DB kümmert sich um Datenhaltung incl. Backup&Restore, (Änderungs&Zugriffs)Protokolle, Schreibrechte und transaktionsbasierte physisch (Referenzielle)Datenintegrität
- die logische Funktionalität, also BusinessLogik steckt im APP-Server, der physisch möglichst nah neben/auf dem
DB Server im Backend läuft... (erst)hier wird die relational
DB Struktur in ein Objekt(relationales)Daten&Funktionsmodell abstahiert. Alle StandardClients greifen nur auf den APP Server zu. Systemtools und Volumen-Interfaces können auch parallel zum AppServer direkt innerhalb des Backenend mit dem
DB Server arbeiten
- viele "dumme" Clients arbeiten nur mit dem APP-Server, denen ist somit die verwendete
DB völlig egal
- wenige "intelligente" Clients oder Interfaces können innerhalb des Backend auch direkt mit den
DB Daten sehr effektiv lesend arbeiten, und ihre Schreibzugriffe sind/werden nach Rechtevergabe von der
DB selbst abgesichert... 90% unserer Kunden fühlen sich einfach gut, wenn sie notfalls mit Tool XY selbst mal lesend ohne viel Administrationsaufwand auf IHRE Basisdaten zugreifen können... wirklich "selbst schreiben" wollen nur ganz wenige in die
DB, und wenn dann sind es meist Kopplungen von Fremdsystemen, wo deren Anbieter gerne etwas automatisieren wollen... und genau solche Schnittstellen realisieren wir
DB intern mit Triggern und allen uns notwendig erscheinenden Validierungen. "Unsere Hauptlogik" steckt im APP-Server und verlässt sich nur auf stimmige von der
DB garantierte (Referenzielle)Datenintegrität.
ps:
"Aber gerade bei Mengenverarbeitungen, die nicht mal angezeigt werden müssen (also klare Batchanwendungen) sind gute Datenbanken dem "Eigenbau" an Leistungsfähigkeit und Performance klar überlegen."
Ein paar Zeilen vorher hat jemand von Zugriffen auf 200Mio Datensätze geschrieben, wo er Standard
DB bevorzugt... wir machen es da genau anders: ab 24Mio Datensätzen arbeiten wir mit eigenen externen BlockBinaryFiles, welche wir per Trigger konsistent über native
DB-AddON schreiben, aber 100% selbst lesend binär im APP Server verarbeiten. Im Finanzumfeld haben wir "mehrfach" hunderte Mio von Datensätzen pro Datenbestand(z.B. auf die Millisekunde genau alle Währungstransaktionen der 9 Hauptwähungen der letzten 10Jahre... das sprengt jeden Standard-
SQL-
DB-Server)