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

[hanvas]

Zitat von Frickler:

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.

[jobo]

Zitat von hanvas:

..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.

Das greif ich doch noch mal auf.

Die Flexibilität im Client hat man nicht zuletzt deshalb, wenn DBServer seitige Möglichkeiten der Regulierung nicht vorhanden sind und oder genutzt werden (dumme Datenbank halt).
Ein Datenmodell serverseitig so abzusichern, dass keine falschen Daten überhaupt erst reinkommen und auch nicht dahingehend manipuliert werden können, dass ein gewünschtes Regelwerk verletzt wird, ist doch der Sinn des ganzen. Das auch noch vor dem Hintergrund, dass selbst komplexe Datenbankoperationen bei einer Verletzung definierter Regeln einfach alles per Rollback zurückdrehen können, zuverlässig, nix passiert, versuchen sie es erneut. Dafür sind DB geschaffen worden (und sie können es mittlerweile sehr gut).
Wenn man alles im Client macht, muss man sich tatsächlich fragen, wofür man eine DB braucht oder wieviel ihrer Fähigkeiten.
Hier war z.B. die Rede von Highvolume Daten im mehrstelligen Millionenbereich, Bank, Börse ...
Wenn ich keine konkurrierenden Schreibzugriffe darauf habe und wenn die Daten von Natur aus eher Log Charakter als alles andere haben, ja, dann muss ich mich oder die DB nicht damit quälen. Referentielle Integritätsprüfung und anderer Zirkus wird hier vermutlich auch nicht stattfinden.
Hier kommt dann ggF. auch hinzu, dass ich diese Daten dem AppServer viel direkter zur Verfügung stellen kann, als es in einem klassischen Appserver - DB Gespann erfolgt. Jegliche Logik, Prüfung etc. die der AppServer durchführt, erfordert den Transport der notwendigen Daten zum Appserver (wurde hier auch schon beschrieben, wahlweise könnte man hier auch Clientprogramm sagen, wenn die Daten eben in Delphi durchgenudelt werden um das Ergebnis 42 zu errechnen). Da kann mir niemand erzählen, dass die gleiche Logikprüfung mit zwischengeschaltetem Transport der Daten gleich schnell oder schneller ist, als ohne diesen Transport. Anders sieht es natürlich aus, wenn die DB wirklich dumm ist und bestimmte Algorithmen nicht beherrscht, die auf dem Client/Appserver verfügbar sind. Dann kann ich außerhalb der DB schneller sein.

Ja und so weiter und so weiter. Mein Fazit, ich weiß, warum ich schlaue DB lieber mag. Aber, it depends.

Was ich an dem Thema außerdem spannend finde, dass es so ambivalent für viele ist.
In Delphi und anderen Sprachen wird teilweise sehr viel Wert gelegt auf die hohe Kunst des Programmierens. Exaktheit der Datentypen, etc. pp.
Die dumme Datenbank hingegen wird da trotz ihres Potentials gerne ignoriert, oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

[mkinzler]

Zitat:

oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

Begründung, um "flexibel" zu bleiben ...

[Lemmy]

Zitat:

oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Zitat von jobo:

Was ich an dem Thema außerdem spannend finde, dass es so ambivalent für viele ist.

ganz einfach weil es "die" Lösung nicht gibt....

[p80286]

Zitat von Lemmy:

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

Gruß
K-H

[Frickler]

Vielen Dank für die vielen guten Anregungen. Ihr seid echt super!

[Lemmy]

Zitat von p80286:

Zitat von Lemmy:

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

es gibt halt Länder da wird es mit der Geburtsurkunde nicht so genau genommen. Und wenn jemand nur weiß, dass er in Jahr x geboren wurde, dann kommt so ein Datum zu Stande.

[p80286]

Zitat von Lemmy:

Zitat von p80286:

Zitat von Lemmy:

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Interessantes Datum, erinnert mich an Fälle in denen "Sehr geehrte Frau Müller" in der Anrede steht und unter Gender "male"....

es gibt halt Länder da wird es mit der Geburtsurkunde nicht so genau genommen. Und wenn jemand nur weiß, dass er in Jahr x geboren wurde, dann kommt so ein Datum zu Stande.

Verständlich aber trotzdem, Ja und?
wenn eine Person ihr Geburts-(Kalender)-Datum nicht kennt, also diese Information nicht vorliegt, dann wird sie auch nicht eingetragen!
Ja irgendwann 1982 geboren? Wenn diese Information abgespeichert werden soll, daran muß der Designer der DB denken! , dann eben nicht in ein DateField, sondern in ein "YearofBirth"-Feld, und "MonthofBirth" und "Dayofbirth" darf leer (NULL) bleiben.
Sind das Numerische Felder? Kommt darauf an, wenn man mit ihnen rechnen will, wäre es empfehlenswert.

Gruß
K-H

[p80286]

Zitat von jobo:

Die dumme Datenbank hingegen wird da trotz ihres Potentials gerne ignoriert, oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

Was bitte ist ein Datetyp?

Gruß
K-H

[jobo]

Zitat von p80286:

Zitat von jobo:

Die dumme Datenbank hingegen wird da trotz ihres Potentials gerne ignoriert, oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

Was bitte ist ein Datetyp?

Ja, äh also, .. komm wir gehen mal nach draußen...

Zitat von Lemmy:

Zitat:

oft schafft man es nicht mal ein Datumswert wie z.B. Geburtstag mit einem Datetyp in die Tabelle aufzunehmen...

weil z.B. auf der eGK ein Geburtsdatum auch mal als 00.00.1982 abgelegt sein kann. Viel Spaß beim Speichern in einem TDate Feld.

Zitat von jobo:

Was ich an dem Thema außerdem spannend finde, dass es so ambivalent für viele ist.

ganz einfach weil es "die" Lösung nicht gibt....

Ja, es gibt ja verschiedene Datumstypen, lass Dir das mal bitte von p80286 erklären.
Aber wofür/gegen spricht das nun?

Und ja, DIE Lösung gibt es nicht, aber wie widersprüchlich viele mit Ihrem Code/Daten da umgehen, erschließt sich mir nicht.