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

[Lemmy]

Zitat:

Zitat von p80286 (Beitrag 1361783)

Wenn diese Information abgespeichert werden soll, daran muß der Designer der DB denken!

genau meine Meinung. Und die widerspricht (nichts anderes wollte ich damit aussagen), der pauschalen Aussage, dass ein Geburtsdatum in einem Datumsfeld gespeichert werden muss.

[mkinzler]

Man sieht aber oft Tabellen, in denen alle Felder vom Typ String (Char()/VarChar()/NVarChar, ...) sind.

[p80286]

Zitat:

Zitat von Lemmy (Beitrag 1361787)

Zitat:

Zitat von p80286 (Beitrag 1361783)

Wenn diese Information abgespeichert werden soll, daran muß der Designer der DB denken!

genau meine Meinung. Und die widerspricht (nichts anderes wollte ich damit aussagen), der pauschalen Aussage, dass ein Geburtsdatum in einem Datumsfeld gespeichert werden muss.

Klingt kleinkariert aber, irgendwann (00.00) in 1982 ist kein (Kalender)Datum, darum kann und darf es nicht in ein Datumsfeld. Das es große Ähnlichkeit mit einem Datum hat, geschenkt.

Gruß
K-H

[nahpets]

Zitat:

Zitat von bra (Beitrag 1361782)

Was hier als Kriterium seltsamerweise noch gar nicht zur Sprache kam ist, welche Datenbanken überhaupt unterstützt werden. Wenn man sich nur auf eine spezielle konzentriert ist es sicher weniger ein Problem die Logik in der Datenbank unterzubringen, als wenn man verschiedene Datenbanken unterstützt.

Die Antwort darauf ist meiner Meinung nach banal:

Wenn ich datenbankunabhängig sein muss, dann ist die Logik datenbankunabhängig in der Software.

Wenn das nicht geht, dann muss ich die Logik (jeweils datenbankspezifisch) mehrfach implementieren.

Oder nur das der Datenbank überantworten, was garantiert alle Datenbanken als Schnittmenge zur Verfügung stellen. Das kann ggfls. extrem wenig sein.

Zum Thema Datum:

Ein Datum, das kein Datum ist, wird nicht als Datum gespeichert.

Welche Alternative ich wähle, hängt von der Fachlichkeit (und ggfls. den datenbankspezifisch möglichen Alternativen) ab.

[grl]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1361784)

Wenn das Geburtsdatum nicht genau bekannt ist, wird dann nicht (amtlich) eines festgelegt?

Was zumindest bei österreichischen Sozialversicherungen zu ganz interessanten Daten führt:
es wird nur der Teil in ein Datum übernommen, der nachweisbar ist, der Rest durch unmögliches ersetzt.
Wenn also jemand ein Geburtsjahr 1975 nachweisen kann aber keinen genauen Geburtstag dann wird z.B. der 28.15.1975 als sein Geburtsdatum von der Sozialversicherung festgelegt und auch als "Geburtsdatum" bezeichnet.
Welches Datum da verwendet wird hängt davon ab wie viele es schon mit dieser Kombination gibt - es wird einfach der nächste freie genommen.

Ganz besonders lustig ist das, wenn man irgendwann eine DB designt hat mit einem Feld "Geburtsdatum" für eine Adresse und das auch kräftig verwendet - um ein Alter anzuzeigen, Altersrabatte zu berechnen usw.

Und dann steht plötzlich einer mit so einem "Geburtsdatum" im Laden....

Gruß
Luggi

[MichaelT]

Es gibt tatsächlich gut Argumente für eine Zwischenschicht. Serverdatum und Zeit (GMT) vs. Lokale Zeit oder wie in SAP in dem hinter einer Domäne ein Datum vom Max Datum wird abgezogen damit man schneller sortieren kann, wenn bspw. Währungsumgsrechnungen werden gepflegt. Die tagesaktuelle Umrechnung ist spannender im Fall von OLTP und war auch oft abgegriffen.

Die Domäne hängt oft auch stark ab von den angeboten Indizierungsvarianten usw...

Bei heise war vor kurzem Artikel über Microservices und jeder Service hätte sein eigenes Schema. In solchen fällen von physischer Partionierung um der wohlgestalt eines Microservices willen wäre mir persönlich zu gewagt. Da wäre das DataModule als ein Vertreter von Schemen eine ganz guter Strukturierungsmechanismus.

Bisher hat sich die Entwicklerschaft gerne mit der Unzulänglichkeit der Web Scripting Technologien aus der Affäre gezogen. Der gemeinsame Nenner war der DB Client auch wenn bspw. die PHP Runtime diese versteckt so gab es lange (und heut auch noch nicht sauber) Data Services die ähnlich einer Datenbank anzusprechen wären. Die gab es praktisch nur im Umfeld von Delphi und selbst wenn die Alternativen vor langer Zeit nach den Midas Replacements DataAbstract und ThinDAC (außer Konkurrenz) waren.

Meine Erfahrung im Umfeld der Datenbanker war schon, dass beide, sowohl der Anwendungsentwickler als der DB Admin oder Business Supporter das selbe Ergebnis sollen sehen können und auf dem selben Weg dazu kommen.

Zitat:

Zitat von mkinzler (Beitrag 1361788)

Man sieht aber oft Tabellen, in denen alle Felder vom Typ String (Char()/VarChar()/NVarChar, ...) sind.

[p80286]

Zitat:

Zitat von mkinzler (Beitrag 1361788)

Man sieht aber oft Tabellen, in denen alle Felder vom Typ String (Char()/VarChar()/NVarChar, ...) sind.

Das ergibt sich (auch) aus der Art der verwalteten Daten. Nicht alles was Ziffern enthält ist auch numerisch!
(Je moderner die Excelversion, desto interessanter als was Aktenzeichen und Erteilungsnummern interpretiert werden. Diese Halbintelligenz davon zu überzeugen, daß Ziffern nicht das gleiche ist wie Zahlen, ist immer wieder aufbauend.)

Gruß
K-H

[WInfo]

Sagen wir mal so, alles was zur Sicherstellung der Datenintegrität gehört in die DB, was nicht, gehört halt nicht in die DB somdern in die Anwendungsschicht. Wenn es daneben um die Representation der Daten geht, muss die DB halt auch noch mal ran und die Daten passend zumSQL Statement zusammenkrallen. Aber das ganze sollte beidseitig auf Standard SQL aufbauen, damit man im Notfall auch eine DB tauschen kann :) Das heist also, bezüglich der Eingangsfrage, sowohl als auch :)

Noch was persönliches, ich bin kein Freund davon der DB zu viel Logik mitzugeben, das macht einfach Änderungen und Anpassungen extrem aufwändig. Was besonders viel wiegt, da ich einfach zu pflegende Systeme bevorzuge :)

WInfo