Bekomme Inner Joins nicht hin

[rokli]

Beispiel solch einer Definition MS SQL Server Management Studio

Code:

CREATE TABLE [dbo].[tblName](
   .
   .
   .
   [DatAuf] [datetime] NULL CONSTRAINT [DF_tblName_DatAuf]  DEFAULT (getdate()),
   [UsrAuf] [varchar](124) NULL CONSTRAINT [DF_tblName_UsrAuf]  DEFAULT ((((('Pc: '+host_name())+'; User: ')+suser_sname())+' - ')+app_name()),
   [DatAen] [datetime] NULL,
   [UsrAen] [varchar](124) NULL,
   .
   . usw

[Jumpy]

Wir arbeiten hier mit einer Software mit über 1000 Tabellen, alls großteils historisch gesteuert, das ist ja sowas ähnliches wie deine Revisionen.
Die Infos dazu stehen jeweils in der Tabelle selber, in unserem Fall eine Art GültigVON und GültigBis Datum für den Datensatz.

Der Vorteil ist, wie du selber schon gemerkt hast, das die Abfragen einfacher werden, wenn du wissen willst, was der gerade aktuell gültige Datensatz ist. Wenn du daher aktuelle Items mit aktuellen Foos joinen willst und sowohl für Items als auch Foos musst du die Revisionstabelle dazu joinen oder abfragen, wird es schnell unübersichtlich und evtl. auch langsam.

Allerdings ist deine Intention mit der Revisionstabelle natürlich auch sinnvoll und dafür gibt es bei uns ein ChangeLog/ChangeHistory Tabellen Konstrukt, dass zwar nicht optimal (gewachsene Struktur) ist, aber man kann sehen wer hat was wann geändert (leider nicht warum).

[mkinzler]

Grundsätzlich ist Normalsisierung (bzw. SnowFlaking) sinnvoll. Man kann ja auch einen (Join-)View erstellen.

[jfheins]

Um dir noch etwas Lesestoff zu geben: Du hast da eine SCD (Slowly Changing Dimension)
Es gibt verschiedene Ansätze, wenn du die Historie behalten möchtest nur Typ 2 oder 3.

Bei Typ 2 kannst du die nicht mehr gültigen Daten in eine eigene Tabelle auslagern, muss aber nicht. Wichtiger wäre, dass du immer ein "Gültig bis" Datum drin speicherst, wenn das NULL ist, ist diese Zeile gültig.
Wenn du den Primary Key nicht auf dieses Feld erweitern möchtest, würde ich es auf zwei Tabellen splitten - siehe Beitrag von mkinzer:

Zitat von mkinzler:

Du hast Items, von welchem (1 zu n) Revisionen bestehen.

Und so allgemein solltest du dir überlegen, nicht nur einen Kommentar zu speichern, sonder auch, was sich geändert hat

[jobo]

Mein Senf:
Ich versteh die Trennung, die (eigene) innere Ordnung der Dinge, die man erhalten möchte.
Das ist auch legitim und m.E. ebenso legitim, an dieser stelle "Insider Wissen" einzusetzen und bereits eine Trennung vorzunehmen, wenn sie faktisch in der bevorstehenden Version noch nicht benötigt wird.
Normalisierung ist kein Selbstzweck, sondern hat primär einen ganz simplen und wichtigen Grund:
Konsistenz

Wenn man sein Datenmodell so konstruiert, dass Konstistenz (garantiert) gewahrt bleibt, hat man nichts verkehrt gemacht. Den Zusatzaufwand treibt man aber nicht aus Vergnügen, es sollte schon irgendwelche Gründe geben, die nicht nur einem selbst bekannt (und akzeptiert) sind.

Bei einer Historisierung oder Revisionen hier wäre es m.E. wichtig dafür zu sorgen, das ein Basiszugriff auf aktuell gültige Daten per Default erfolgt. Das würde hier heißen, mit Views zu arbeiten, die Altdaten automatisch ausblenden.
Ausnahme wäre ggF. wenn die Historie teil des Business Case ist und irgendwelche Spezialisten ständig mit verschiedenen Ständen arbeiten (müssen).


Gerade erst gesehen:
Ist das vielleicht nur eine Fake Frage, weil DSG hier
https://www.delphipraxis.net/199015-...ml#post1421208
nicht weiter kommt?