Bekomme Inner Joins nicht hin

[mkinzler]

Ich sehe in diesem Fall nicht das Problem der Normalisierung sondern das Design der Tabellen

[Der schöne Günther]

Ok, wir haben schon jetzt ein handfestes Problem? Dann helft mir bitte doch am besten jetzt 😓

[Uwe Raabe]

Ich bin mir nicht sicher, wie diese Aussage zu verstehen ist:

Zitat:

Ich habe in meiner Datenbank "Items". Wenn diese verändert werden soll der alte Stand nicht gelöscht werden, sondern ein neuer hinzugefügt werden wo die Revisionsnummer höher ist.

Wenn du also einen Eintrag in der Tabelle Item veränderst (z.B. Daten1 und/oder Daten2), wird wohl in jedem Fall ein neuer Datensatz in Item-Rev angelegt. Wird in Tabelle Item dann auch ein neuer Eintrag mit derselben ID aber den neuen Daten-Werten und der neuen rev angelegt?

[mkinzler]

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

Item
ID ( PK; autoinc)
DESC (altes Feld ID)
Daten1
Daten2

Rev
ID (PK; autoinc)
Item ( FK auf Tabelle Item Feld ID)
Changed
Comment

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1421230)

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:

Zitat von mkinzler (Beitrag 1421231)

...

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.

[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.

[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

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1421236)

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:

Zitat von Der schöne Günther (Beitrag 1421236)

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:

Zitat von Der schöne Günther (Beitrag 1421236)

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.