AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Datenbankdesign: Den Grad des Hirnrisses bestimmen
Thema durchsuchen
Ansicht
Themen-Optionen

Datenbankdesign: Den Grad des Hirnrisses bestimmen

Ein Thema von Furtbichler · begonnen am 19. Okt 2012 · letzter Beitrag vom 23. Okt 2012
 
Furtbichler
(Gast)

n/a Beiträge
 
#5

AW: Datenbankdesign: Den Grad des Hirnrisses bestimmen

  Alt 19. Okt 2012, 15:16
Ich finde sowas sogar so "brauchbar"
Ich nicht, denn ein FK-Constraint ist so nicht möglich.
Zitat:
Es geht doch darum, die Möglichkeiten eines Systems intelligent und effizient auszunutzen. Daran hindert mich höchstens der Kunde selbst.
Natürlich müssen solche Verfahren angemessen dokumentiert sein.
Ich glaube, man hat ein Designproblem gemacht, wenn man diese Art der FK-Referenzierung betreibt.

Und: Ja, ich breche das 3NF-konform (nun, sagen wir 2.7NF) herunter und es gelingt mir sehr gut. Hinterher freue ich mich, wie stringent und transparent ich Erweiterungen umsetzen kann.
Vielleicht kannst du es ja anders anfangen und darum bitten, dir die Gründe für dieses Design zu erklären.
Genau das werde ich machen, denn der PM ist ein sehr fähiger Kopf. Vermutlich sind das Altlasten, die auch an seiner Ehre nagen: Aber man kann so ein Design nicht einfach wegradieren.

Vielleicht war es auch eine gewachsene Applikation, .. oder ein Entwickler, der solche Grenzen im Kopf hatte.
Super schlußgefolgert: Dieses Argument (argh! Die DB wird soo groß! Bei 10 Mio Records) höre ich immer wieder. Und gewachsen ist es ja.
Die Zugriffszeiten waren häufig direkt proportional der Menge der gespeicherten Daten in einer Tabelle.
Ich glaube langsam auch, das das historisch bedingt ist. Bezüglich deines Vorschlags. Mir geht es nicht um die Lösung zu diesem Problem, denn das geht eh nicht ohne massive Änderungen an der Software und langsfristig wollen wir eh weg von der Lösung.
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 ...
Leute, es ist doch echt witzig: Ich beschreibe ein Fragment einer bekloppten Umsetzung (DB-Design) und nacheinander ist die Community in der Lage, die Historie dieser Applikation genau zu erzählen:

Es ist eine über die Jahre gewachsene Applikation, die vermutlich ihre Anfänge dort nahm, als Speicher noch teuer war und heute werden -wie Sir Rufo treffend bemerkt- Änderungswünsche über den kleinen Dienstweg gebastelt. Gerade gestern ist eine neue Tabelle 'A23' hinzugekommen ist.

Mittlerweile bemerken die das auch und haben ein Szenario entworfen, was passiert, wenn man einen Datensatz ändert und was das für Auswirkungen hat.

Es ist grauenhaft und ich möchte zu meiner Mama.

Ich kann also als Fazit, das es *nicht* state of the art ist, ziemlicher Blödsinn und die einzige plausible und entschuldbare Erklärung die der bekannten "Altlasten" ist, deren Elimination beauftragt werden müsste. Richtig?

Ich werde auch, danke Uwe Raabe, freundlich nachfragen, ob es einen tieferen Sinn gibt.

PS: Danke für die wirklich amüsanten Anekdoten und Einschätzungen, die doch so ziemlich alle ins Schwarze getroffen haben.
  Mit Zitat antworten Zitat
 


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:36 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-2025 by Thomas Breitkreuz