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

[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

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