Bekomme Inner Joins nicht hin

[Der schöne Günther]

Zitat von Uwe Raabe:

Wird in Tabelle Item dann auch ein neuer Eintrag mit derselben ID aber den neuen Daten-Werten und der neuen rev angelegt?

Ganz genau.

Vorher:
Item:

id	rev	Daten1	Daten2
"ABC/123"	1	"Waffel"	3.14

Item_Rev:

id	changeTimestamp	changeComment
1	2018-12-18	"Item angelegt"

Nachher:
Item:

id	rev	Daten1	Daten2
"ABC/123"	1	"Waffel"	3.14
"ABC/123"	2	"Bohnen und Speck"	3.14

Item_Rev:

id	changeTimestamp	changeComment
1	2018-12-18	"Item angelegt"
2	2018-12-19	"Wir brauchen unbedingt Bohnen"

Zitat von mkinzler:

...

Danke für die Alternative. Wo die Vorteile sind muss ich jetzt noch meditieren...

[Uwe Raabe]

Gemäß deinem vorher/nachher Beispiel kannst du die Felder der beiden Tabellen auch in eine Tabelle zusammenfassen. Es existiert zu jedem Item-Datensatz ja auch genau ein Datensatz in Item_Rev. Das macht die Trennung in zwei Tabellen eigentlich überflüssig.

Wenn du das in einer Tabelle realisierst, fällt das Item_Rev.ID Feld ja weg, da es dem Item.rev Feld entspricht. Da das Item.ID Feld aber kein AutoInc-Feld sein kann, bietet sich an, das Item.rev Feld als AutoInc anzulegen, damit die Revisionen automatisch hochgezählt werden. Damit ist gewährleistet, daß neuere Datensätze immer einen höheren rev-Wert haben.

[rokli]

Möglicherweise hilft Dir noch die Info, dass es bei MS SQL einen Feldtyp Namens DATETIME gibt.

Das Feld ANLAGE_DATUM, mit dem Default GEDATE() definiert, verwende ich in quasi jeder Tabelle. Beim anlegen eines Datensatzes sorgt der Konstrukt dafür, dass Du automatisch die genau Datum und Uhrzeit zum Datensatz speicherst.

[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

[Der schöne Günther]

Vielen Dank für die Geduld und Erklärungen bislang.

Ich sehe ein dass man es eigentlich auch in eine Tabelle packen könnte. Ich sehe noch nicht was ich dadurch gewonnen habe - Ich finde es so sehr sympathisch halt ein Feld "rev" zu haben, und sonst nichts als das "Item". Mit Kommentar, Zeitstempel usw. "verunreinige" ich mMn ein bisschen die Tabelle "Item".


Außerdem ist die Tabelle "Item_Rev" völlig neutral gegenüber einem "Item". Eigentlich könnte ich sie sogar "Revisionen" nennen und für alles nutzen, nicht nur Items.

Wenn ich eines Tages noch anfange zu Revisionen z.B. nicht nur einen Freitext-Kommentar sondern einen Benutzernamen zu speichern müsste ich dann auch nur die Tabelle "Revisionen" anpassen - Und nicht alle Tabellen wo etwas revisioniert wird.

[Uwe Raabe]

Zitat von Der schöne Günther:

Ich sehe ein dass man es eigentlich auch in eine Tabelle packen könnte. Ich sehe noch nicht was ich dadurch gewonnen habe - Ich finde es so sehr sympathisch halt ein Feld "rev" zu haben, und sonst nichts als das "Item". Mit Kommentar, Zeitstempel usw. "verunreinige" ich mMn ein bisschen die Tabelle "Item".

Solange zwischen beiden Tabellen eine 1:1 Beziehung herrscht, ist eine künstliche Trennung der Felder in separate Tabellen und datentechnisch nicht erforderlich.

Zitat von Der schöne Günther:

Außerdem ist die Tabelle "Item_Rev" völlig neutral gegenüber einem "Item". Eigentlich könnte ich sie sogar "Revisionen" nennen und für alles nutzen, nicht nur Items.

Das würde dann aber der oben genannten 1:1 Beziehung widersprechen. Es gäbe dann nämlich Sätze in "Revisionen", die keinen Partner-Datensatz in "Items" haben.

Zitat von Der schöne Günther:

Wenn ich eines Tages noch anfange zu Revisionen z.B. nicht nur einen Freitext-Kommentar sondern einen Benutzernamen zu speichern müsste ich dann auch nur die Tabelle "Revisionen" anpassen - Und nicht alle Tabellen wo etwas revisioniert wird.

Es ist ziemlich aussichtslos, eine DB-Struktur auf eventuell denkbare, zukünftige Anforderungen hin zu entwerfen. Wir können auch nur das beurteilen, was du uns hier beschreibst - nicht das, was du eventuell in Zukunft vorhast.

[p80286]

Zitat von Uwe Raabe:

Es ist ziemlich aussichtslos, eine DB-Struktur auf eventuell denkbare, zukünftige Anforderungen hin zu entwerfen. Wir können auch nur das beurteilen, was du uns hier beschreibst - nicht das, was du eventuell in Zukunft vorhast.

Einspruch, nur wenn definitiv ausgeschlossen ist, daß es keine zwei oder mehr Revisionen zu einem Item gibt, dann könnte man über eine Tabelle nachdenken. Und wenn man eine 1:n Beziehung von vorneherein in Betracht zieht, ist man auf der sicheren Seite.
Ausnahmen die es nieee geben wird sind zum

Gruß
K-H