Datenbankdesign: Den Grad des Hirnrisses bestimmen

[mkinzler]

Zu 1.) Eine Trennung in Tabellen nach Jahren ist eigentlich unnötig, es herrscht aber oft die Vermutung, dass es schneller sei/wird wenn die Anzahl der DS geringer ist/man diese verringert.
Eine tabellarische Trennung nach Kundenarten(-erkunft) macht imho noch weniger Sinn ( höchstens man benötigt verschiedene Rechnungskreise).
Zu 2.) Wenn man schon 1. prakiziert sollte man das dann konsequent tun und auch die Detailtabellen trennen.

[jobo]

Ich geh mal davon aus, dass es bei den Problemen nicht um Mandantenverfahren handelt.

Trennung der Tabelle nach Kriterien (Jahr) wird allgemein als Partitionierung bezeichnet und vom RDBMS selbst durchgeführt, sofern es dazu in der Lage ist (die teure Option gekauft/lizensiert wurde)
Was Du schreibst ist also gewissermaßen Partitionierung für Arme. Ich halte es je nach Umständen/Historie des Produkts, etc. für legitim. Insbesondere, wenn es eine logische Schicht gibt (einfache Union Views), die für einen generellen Zugriff auch die Gesamtsicht liefern.
(Z.B. wenn das Datenvolumen in den Terrabytebereich geht, irgendwann kommt der Performanceunterschied, oder Produktivdaten, die sehr stark am Geschäftsjahr orientiert sind- und später uninteressant bzw eher DWH Charakter haben- ohne das ein DWH da ist)
Variable Relationen

Wenn es gut modelliert ist, finde ich auch das nicht "schlimm".
Beispiel "Adresse":
Nimm eine Firma (Standort, Produktion A, B, ..) und Personen, die in der Firma arbeiten. Alle haben Adressen. Nun kann man je nach Anforderung
a) die Firma gar nicht abbilden (außer im denormalisierten Firmennamen des MA- der immer wieder auftaucht)
b) Firma und Mitarbeiter identisch "modellieren" und in eine (juristische)PersonTabelle packen. Man spendiert noch ein paar entweder oder Spalten je nach Typ oder verschiedene 1:1 Tabellen, die spezifische Daten ausmodellieren
c) man verwendet von vornherein verschiedene Tabellen für Firmen und Mitarbeiterm, trotzdem haben beide eine Adresse (und Telefon und Email ... je nach Sicht)
Sowas macht man nach rei(f/ch)licher Überlegung und mit einer perfekten Absicherung im Backend. (siehe auch Dein eigener Beitrag zu ERP, btw: ich hab es mir noch nie angetan ein ORM Datenmodell eines komplexen Systems zu produzieren oder zu analysieren, vermutlich annotiert man sich tot, um etwas brauchbares hinzubekommen )

Ich finde sowas sogar so "brauchbar", dass ich eigentlich nur darauf warte, wann soetwas logisch von einem RDBMS unterstützt wird. (was wohl nie passieren wird)
Noch was:
Eine solche variierte Referenzierung kannst Du im Backend so wrappen, dass es niemand merkt, den es nichts angeht (Entwickler, Kunden).
Ob das gegen eine (wissenschaftliche) Norm verstößt, wäre mir ziemlich egal. 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.

Ein weiterer Stichpunkt wäre noch Zugriffs / Rechtekonzept.
Falls ein RDBMS keine inhaltsorientieren Berechtigungskonzepte mitbringt, könnte es auch zu solchen "Lösungen" führen. Vorstellbar wäre z.B. eine Schmiergeldtabelle je nach Himmelsrichtung. Die darf natürlich nicht jeder bearbeiten oder sehen, etc. pp blabla

[Blup]

Gerade bei älteren Projekte waren zum Zeitpunkt des Entwurfs noch keine SQL-Datenbanken geplant.
Die Zugriffszeiten waren häufig direkt proportional der Menge der gespeicherten Daten in einer Tabelle.
Deshalb hatte es da durchaus Sinn ältere oder wenig gebrauchte Daten auszulagern.
Bei einem späteren Umstieg wird in der Regel kein Datenbankdesigner beauftragt, kostet ja alles erst einmal Zeit und Geld. Man verändert das Konzept nicht sondern verlagert nur die Daten. Damit spart man auch gleich den Aufwand die Abfragen im Programm zu optimieren. Solange die Software damit alle gestellten Anforderungen erfüllen kann, ist auch alles in Ordnung. Ist das nicht mehr der Fall, hat man natürlich das Problem dem Kunden klar zu machen, daß eine Weiterentwicklung nur mit einer relativ aufwendigen Änderung der Grundstrukur möglich ist.

- Analyse der vorhandenen Anwendungsfälle und Anwendungstest entwickeln
- neue Datenstruktur entwickeln
- Ersetzen der alten Tabellen durch DB-View und/oder DB-Procedure für alte Programmteile
- Konvertierung der Daten
- Testen

Zitat:

2. Spalte als "Foreign Key" zeigt auf unterschiedliche Tabellen.
Ich habe drei Tabellen: A1, A2 und B. B enhält eine Spalte 'FID' und eine Spalte 'FTBL'.
In FID steht eine ID drin. Wenn in FTBL der Wert 'A1' steht, dann ist die ID der PK von A1. Steht in FTBL 'A2', ist die ID der PK von A2.

Das hört sich eigentlich so an als währen A1 und A2 Rollen von B.
Dann ist die ID in A1, A2 und B Primärschlüssel, in A1 und A2 zusätzlich "Foreign Key" auf B.
B <- A1
B <- A2
Als Objektmodel:
- Das Objekt wird immer mit ID und den Eigenschaften der Basisklasse in B gespeichert.
- Für Ableitungen(A1) werden unter der selben ID in der Tabelle A1 die zusätzlichen Eigenschaften gespeichert
- Für Ableitungen(A2) werden unter der selben ID in der Tabelle A2 die zusätzlichen Eigenschaften gespeichert

[Furtbichler]

Zitat von jobo:

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.

Zitat von Uwe Raabe:

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.

Zitat von joachimd:

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.

Zitat von Blup:

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.

Zitat von Sir Rufo:

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.

[p80286]

Zitat von Furtbichler:

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?

Hmm, mit "state of the art" habe ich so meine Probleme.
Es gab schon soo viele Luftschlösser/Bruchbuden, die als Lösung aller jetzigen und zukünftigen Probleme verkauft wurden, solange es eine Lösung tutet solange ist sie brauchbar, egal ob ISAM,Rel.Datenbank oder Cloud.
Wer hatte "the cloud" noch mal mit Wolkenkuckucksheim übersetzt?

Gruß
K-H

[Elvis]

Solche Tabellen können auch bei der Verwendung eines ORM entstehen.

öfter als man erwarten würde, entscheidet man sich dabei nämlich dafür eine eigene Tabelle für bestimmte Ableitungen zu haben.
Auf der anderen Seite einer Assoziation wird dann der ORM eine "Discriminator column" anlegen, damit er sofort weiß was er wie abzufragen hat.

Habe ich selbst schon öfters benutzt, einfach weil der Profiler meinte es sei schneller.

Foreign keys sind IMO überbewertet. Zumindest wenn man einen ORM einsetzt. Aber das kommt sicherlich auf den Use-case an. Vor allem ob direkter Zugriff auf die DB ermöglicht werden soll.

[FaTaLGuiLLoTiNe]

Zitat von Furtbichler:

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

Weiss deine Mama, wie man Entity-Relationship-Modelle erstellt?