SQL Tabelle mit Untertabelle
-
Jetzt hast du beschrieben, was du machst, aber immer noch nicht warum du das ganze machst. Vielleicht kennt dann ja jemand einen Alternativvorschlag, bei dem du das Foreign-Key-Problem nicht hast.
-
Ah, ok.
Ich mache das, weil eine Gruppe von Leuten eine Informationsdatenbank nutzen möchte. Darin werden Werte gespeichert, die zu einem Gerät gehören.Jetzt werden die Geräte hin und wieder weiterentwickelt, wodurch sich die Informationen in der Datenbank ändern können. Kommt jedoch ein älteres Gerät zu Reparatur, muss ich auf den dazugehörigen Informationsstand zugreifen können.
Zu jeder Entwicklungsstufe gehört also eine Tabellenversion.
Nun könnte man ja sagen, rekonstruiert man einfach die gesammte Datenbank. Dann können aber nicht 100 unterschiedliche Entwicklungsstufen gleichzeitig repariert werden.
-
Hab ich so halt noch nicht gesehen, dass man für jede Produktversion neue Tabellen erstellt, aber okay. Unterscheiden sich die Versionen denn so sehr, dass man für jede eine eigene Tabelle braucht oder würde nicht auch eine Tabelle mit einer Versionsspalte reichen?
-
Also ich hab das hier sehr vereinfacht dargestellt. In wirklichkeit besteht jede Version aus einem ganzen Tabellensatz (ca. 20), wobei ich nur eine Kopie für eine neue Version Anlege, wenn sich tatsächlich auch etwas geändert hat.
Über meine Versionstabelle weise ich dann einer großen Versionsnummer die zugehörigen Tabellennamen zu.
Die Tabellen selbst unterscheiden sich mitunter nur in einem Eintrag. Ich hab auch schon an inkrementelle Änderungstabellen gedacht, aber da wird denk ich in naher Zukunft der Aufwand zur Rekonstruktion so groß, dass ich ein Problem krieg. Und es ist eben unerlässlich, dass mehrere Personen gleichzeitig auf unterschiedliche Versionsstände zugreifen können.
Ich find, da war das mit der Versionstabelle schon die beste Idee von denen, die mir dazu gekommen sind.
-
Spontane Idee:
Nur ein Tabellensatz pro Produkt, jeweils mit einer Versionsspalte. Spalten, die in einer Version nicht benötigt werden, werden leer gelassen. Programmseitig kann anhand der Versionsspalte entschieden werden, welche anderen Spalten beachtet werden müssen.
Wenn nachträglich viele Spalten hinzukommen bleibt da natürlich viel ungenützt, aber wenn das nicht der Fall ist, dann sparst du dir damit den Verwaltungsaufwand mit den vielen Tabellen.
Um nachträglich Spalten hinzuzufügen kannst du ja ein Database Refactoring Tool wie liquibase verwenden.
-
Wie greifen denn die Geräte auf die Datenbank zu? Nur lesend oder auch schreibend?
Und müssen die Daten in den verschiedenen "Versionen" die du geplant hast auch gepflegt werden, oder reicht es wenn sie an einem bestimmten Punkt kopiert werden, und von da an dann nie mehr mit anderen "Versionen" abgeglichen?
Falls die Daten nie abgeglichen werden müssen, dann mach doch einfach pro Version eine eigene Datenbank. Je nach Version des Geräts verbindest du dich bzw. das Gerät dann zu einer anderen Datenbank. Problem gelöst.
Falls die Daten jedoch abgeglichen werden müssen, die Geräte beim Service allerdings nur lesend zugreifen, wäre es u.U. möglich, die aktuellen Daten on-the-fly in die jeweils für ein Gerät geeignete Form zu transformieren. Im einfachsten Fall reichen dazu ein paar Views.
Redundante Daten in verschiedenen Versionen sind auf jeden Fall die Hölle, wenn alle alten Versionen noch gepflegt werden müssen. Ich würde auf jeden Fall versuchen das zu vermeiden.
-
Die Daten sind ja im Prinzip nicht redundant. Jede Version ist "formal" unabhängig von allen anderen. Und bestehende Versionen können natürlich nicht geändert werden, sondern dazu muss immer eine neue Version generiert werden, im Zweifel als Unterversion der vorherigen.
Nur eine Tabelle für alle Versionen zu verwenden habe ich auch mal überlegt. Tue das beispielsweise für verschiedene, verknüpfte Eigenschaften (Mainbord, Festplatte, etc), die alle in einer Tabelle stehen und einen Wert haben, der angibt, es sie sind. Aber bei über 1000 Datensätzen pro Version wird die Datenbank dadurch nicht unbedingt besser, oder?
-
Also wegen den 1000 Datensätzen pro Version musst du dir noch keine Sorgen machen. Datenbanken wurden gemacht um mit Millionen von Datensätzen umgehen zu können, das sollte also kein Hindernis sein.
-
wäre es sogar nicht besser alles in eine Tabelle zu machen? 1000 Tabellen mit je 1000 Datensätzen sind sicher unvorteilhafter als eine Tabelle mit 1.000.000 Datensätzen.
Aber ich würde mir erst Sorgen machen, wenn du keine neuen datensätze einfügen kannst, weil deine bigint-id sonst überlaufen würde
-
Vom Gefühl her ist das für mich eher Geschmackssache. Vom Gefühl her hab ich es besser im Griff, ich verwende einzelne Tabellen. Auch werd ich das Gefühl nicht los, dass ich mir nicht wirklich Redundazen spare. Es würde ja vermutlich so ausehen, oder:
ID | Prop | Version | Value ---+------+---------+-------- 1 | A | 1 | 11 2 | A | 2 | 11 3 | A | 3 | 12 4 | B | 1 | 21 5 | B | 2 | 22 6 | C | 1 | 31 7 | C | 2 | 32 8 | C | 3 | 33Ich muss für jede Property einen Eintrag spendieren, die in einer Version vorkommt, hat sich der Wert geändert oder nicht. Wenn ich überlege dass sich einige Tabellen von Version zu Version gar nicht ändern, spare ich doch mehr, wenn ich einzelne Tabellen verwende und diese nur repliziere, wenn sie sich ändern. Sonst verweist halt der Versionseintrag von verschiedenen Versionen auf die gleiche Tabelle...
-
Machen wir mal Butter bei die Fische.
Was speichern denn diese Datenbanken genau?
-
Das ist die Parameterdatenbank für ein Steuergerät. Die Varianten sind Peripherie und Einsatzgebiete, welche die Parameterwerte beeinflussen können.
-
Ich würde, wie schon vorgeschlagen 1. Tabelle (tabellensatz) machen, mit
allen Feldern die da gebraucht werden.
Für die einzelnen Versionen würde ich dann eine View mit den für diese
Version notwendigen Infos über die Originaltabelle legen und gut is.
