![]() |
AW: Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm
Zitat:
|
AW: Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm
Man sieht aber oft Tabellen, in denen alle Felder vom Typ String (Char()/VarChar()/NVarChar, ...) sind.
|
AW: Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm
Zitat:
Gruß K-H |
AW: Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm
Zitat:
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. |
AW: Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm
Zitat:
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 |
AW: Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm
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:
|
AW: Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm
Zitat:
(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 |
AW: Dumme Datenbank & schlaues Programm vs. schlaue Datenbank & dummes Programm
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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz