Bekomme Inner Joins nicht hin

[Uwe Raabe]

Zitat von Der schöne Günther:

War der Sinn von SQL nicht dass man es über verschiedene Datenbank-Systeme hinweg verwenden könne?

Nein, denn das S in SQL steht nicht für Standard sondern für Structured. Insbesondere gilt für Interoperability and standardization:

Zitat:

SQL implementations are incompatible between vendors and do not necessarily completely follow standards.

Es gibt zwar SQL Standards, aber die definieren in der Regel nur einen kleinsten gemeinsamen Nenner. Es ist mitunter auch gar nicht so leicht zu erkennen, wann man einen solchen Standard verlässt, wenn das aktuelle Konstrukt in der gerade verwendeten Datenbank zufällig noch funktioniert.

[Der schöne Günther]

Danke. Dann fühle ich in meiner Einstellung Bleibe Datenbanken fern solange du kannst ja bestärkt 🤣

[mkinzler]

Und T-SQL ist in vielen Dingen halt "speziell"

[Uwe Raabe]

Zitat von mkinzler:

Und T-SQL ist in vielen Dingen halt "speziell"

SQLite aber auch.

[mkinzler]

Jo.

[EmWieMichael]

Als ausgewiesener NichtSQLGuru habe ich eine Frage zur Datenstruktur:
Warum trennst Du die Daten in zwei Tabellen auf? Wäre es nicht einfacher, die Revisionsdaten DateTime und den Kommentar mit in die Haupttabelle zu nehmen?

Gruß Michael

[Der schöne Günther]

"Einfacher" sicherlich, aber nicht normalisiert.

Vielleicht war es gestern Abend für mich schon zu spät, aber wenn ich es noch richtig im Kopf habe, dann ist das immerhin in dritter Normalform, denn ich habe keine transitive Abhängigkeit.

Hätte ich die Felder "changeTimestamp" und "changeComment" noch mit hereingepackt hätte ich die dritte Normalform nicht, denn Daten1 & Daten2 wären abhängig davon. Wahrscheinlich noch nicht einmal die erste Normalform, denn was haben eigentlich Änderungszeitpunkt und -Kommentar mit einem "Item" an sich zu tun?


http://www.datenbanken-verstehen.de/...ormalisierung/

https://www.php-kurs.com/normalisierung.htm

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

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