Datenbankdesign: Den Grad des Hirnrisses bestimmen

[Sir Rufo]

Zitat von joachimd:

Zitat von Uwe Raabe:

Es mag durchaus Gründe für dieses Design geben oder gegeben haben (kann ich mir zwar nicht vorstellen), aber es mag andere Lösungen dafür geben, die etwas geradliniger sind.

Vielleicht war es auch eine gewachsene Applikation, welche früher an DBF-Grenzen stieß (2GB bzw 4GB, je nach Treiber) - oder ein Entwickler, der solche Grenzen im Kopf hatte. Da wir DBF als natives Storage unterstützen, sehe ich das sehr oft

Mir scheint es eher, als ob da nach der Planungs-/Entwicklungsphase noch ein Änderungswunsch hinzukam, der so fix auf dem kleinen Dienstweg gebastelt wurde. Sollte nix kosten nur eben tuten ...

[stalkingwolf]

Blup hat es auf den Punkt gebracht.
Wenn ein Programm schon mehr als 20 Jahre alt ist, aber funktioniert, dann wird die Logik samt Datenmodell übernommen. Sprich Dos->Windows BDE -> Windows SQL. Dann sieht die Datenstruktur vermutlich wie zu DOS Zeiten aus.
Es gibt ja immer die Theoretiker und dann die , welche praktisch damit arbeiten. Die Theoretiker philosophieren über neue Modelle und Arbeitswege, da haben die anderen das schon programmiert.
Es geht nämlich darum Geld zu verdienen. Und zwar jetzt und nicht in 12 Monaten, wo man vorher evtl schon Pleite ist. Und evtl bei der ganzen Umstrukturierung die Hälfte vergessen hat, oder weg lassen musste, weil es fertig werden muss.

Wenn man natürlich bei einem neuen Projekt das genau so macht, dann sollte man evtl den Job wechseln.

Ich habe schon unzählige Datenübernahmen aus Fremprojekten programmiert. Darunter auch schon aus MS Axapta. Bei einigen Datenmodellen kam man sich vor, als hätte jemand ne Doktorarbeit geschrieben und sich Nachts darauf einen runter... hat. Oder evtl wollte er zum Mond damit.
Sah irgendwie auch gut aus, aber um an die Daten zu kommen, hat man sich nen Wolf programmiert

[mkinzler]

Zitat:

Es gibt ja immer die Theoretiker und dann die , welche praktisch damit arbeiten. Die Theoretiker philosophieren über neue Modelle und Arbeitswege, da haben die anderen das schon programmiert.
Es geht nämlich darum Geld zu verdienen.

Das würde ich so nich grundsätzllich unterschreiben. Das mag grundsätzlich manchmal so gelten. In vielen Fällen lohnt es sich aber verschiedene Lösungen zu betrachten und dann abzuwägen, welcher besser ist. Oft lohnt sich ein wenig Mehraufwand jetzt um einen größeren Mehraufwand in der Zukunft zu vermeiden. zudem verhindern solche Strukturen Möglichkeiten neuer DBMS ( constraints usw.)