2 Tabellen verknüpft, wie garantiere ich gleiche IDs?

Jakob

Jakob

Aktives Mitglied
Thread Starter
Dabei seit
05.01.2004
Beiträge
1.070
Reaktionspunkte
21
Hallo,

aus einem Kontaktformular sollen alle bis auf eine Info + durchgehende ID in eine Tabelle, eine Info + ID in die andere Tabelle.

Wie garantiere ich gleiche IDs in beiden Tabellen? Wenn er aus irgendnem Grund mal nicht in eine Tabelle schreiben konnte, also da ne ID fehlt, sind ja alle folgenden verschoben, oder?
 
Hallo!

Ich würde erst die Daten in die erste Tabelle eintragen, die ID rausholen und diese ID mit den anderen Daten dann in die zweite Tabelle eintragen.

Wenn die IDs mit auto_increment eingetragen werden, muss natürlich bei der zweiten Tabelle diese Funktion abgeschalten werden.
 
Gute Idee... wie würdest Du das Syntaxmäßig machen? Kann ich gleich in der nächsten Zeile auf einen Wert zurückgreifen, der vielleicht vor ner halben sekunde geschrieben wurde?
 
Jakob schrieb:
Wenn er aus irgendnem Grund mal nicht in eine Tabelle schreiben konnte, also da ne ID fehlt, sind ja alle folgenden verschoben, oder?

Um auf solche Situationen zu reagieren, setzt man Transaktionen ein, die sicherstellen, das alle Aktionen (in deinem Fall das Schreiben in beide Tabellen) entweder vollständig oder gar nicht durchgeführt werden.

Ansonsten ist der Tipp von Lindic natürlich richtig, da man in zwei Tabellen auch mit Transaktionen nicht sicherstellen kann, dass die automatischen IDs immer gleich sind, zumindest bei MySQL. Unter Oracle läßt sich das über den Einsatz von Sequenzen machen.
 
Jakob schrieb:
Gute Idee... wie würdest Du das Syntaxmäßig machen? Kann ich gleich in der nächsten Zeile auf einen Wert zurückgreifen, der vielleicht vor ner halben sekunde geschrieben wurde?

Nach dem ersten INSERT-Befehl kannst du mit
PHP:
$id = mysql_insert_id();
die soeben eingetragene ID ermitteln und für das zweite INSERT verwenden.
 
Agmemon schrieb:
Ansonsten ist der Tipp von Lindic natürlich richtig, da man in zwei Tabellen auch mit Transaktionen nicht sicherstellen kann, dass die automatischen IDs immer gleich sind, zumindest bei MySQL.

Es ist aber auch von der Konzeption falsch, den Fremdschlüssel auf die ID in der Tabelle 1 in Tabelle 2 als auto_increment zu führen.
 
Nogger schrieb:
Es ist aber auch von der Konzeption falsch, den Fremdschlüssel auf die ID in der Tabelle 1 in Tabelle 2 als auto_increment zu führen.

Ich hatte das so gemeint:

Tabelle 1: ID -> auto_increment

Tabelle 2: ID -> NICHT auto_increment, sondern Bezug zur ID von Tabelle 1
 
Ich hätte es so gemacht:
Tabelle #1:
Tabelle1.ID (auto_increment) | Tabelle1.Feld1 | Tabelle1.Feld2...

Tabelle #2:
Tabelle2.ID (auto_increment) | Tabelle2.Feld1 | Tabelle2.Feld2...

Tabelle #3:
Tabelle3.ID (auto_increment) | Tabelle1.ID | Tabelle2.ID

Die einzelnen Werte kann man dann in die Tabellen eintragen und am Ende den Datensatz für Tabelle #3 erstellen. Um die beiden Sachen wieder zu "vereinen" nimmt man dann einfach ganz easy den LEFT JOIN. An den IDs würde ich generell nicht herumspielen, das birgt nur Ärger, wenn jemand mal an den Daten fummelt und wenn eine gelöscht wird, stimmt der auto_increment schon nicht mehr etc. Nee das gehört verboten ;-)
 
Die dritte Tabelle ist nur bei n:m Beziehungen nötig. Der Beschreibung nach ist es eine 1:n oder 1:1 Beziehung, und da reicht ein Fremdschlüsselattribut.
 
Wird Zeit die Waffen offen auszulegen: Also in dem speziellen Fall bin ich zu MS SQL gezwungen. Hab mich vorher nicht getraut das zu sagen. Normal mach ich sowas auch mit MySQL, ehrlich! Vielleicht kennt sich ja jemand damit aus und sagt "Achso, ja da geht das ganz einfach!".

Also vereinfacht sieht das Formular so aus:
Name, eMail, noch paar Felder, Bemerkungen

Da viele Mails ankommen, wird eine Tabelle mit allen Feldern mit der Zeit sehr groß denke ich. Ist es da ratsam die Bemerkungen auszulagern oder hat die Größe keinen Einfluss auf die Geschwindigkeit, wenn ich in SELECT und UPDATE Anweisungen die Bemerkungen garnicht anwähle? Also "SELECT name, email" Oder sind bei Text die Geschwindigkeiten eh so marginal verschieden, dass es sich nicht lohnt?

Brauche ich eigentlich IDs? Bin jetzt soweit, als Schlüssel einfach Datum und Name zu nehmen, weil es gegen 0 geht, dass zur gleichen Zeit eine gleich heißende Person was schreibt.
Oder sind IDs trotzdem gut?

Vielen Dank!
 
Jakob schrieb:
Wird Zeit die Waffen offen auszulegen: Also in dem speziellen Fall bin ich zu MS SQL gezwungen. Hab mich vorher nicht getraut das zu sagen. Normal mach ich sowas auch mit MySQL, ehrlich!

Du Schlingel... ;)


Jakob schrieb:
Brauche ich eigentlich IDs? Bin jetzt soweit, als Schlüssel einfach Datum und Name zu nehmen, weil es gegen 0 geht, dass zur gleichen Zeit eine gleich heißende Person was schreibt.
Oder sind IDs trotzdem gut?

Ich würde immer eine ID verwenden, damit die Datensätze wirklich eindeutig sind.

Aber zu MSSQL kann ich dir nicht viel sagen, sollte aber ähnlich gehen wie MySql. Du kannst aber alle Daten in eine Tabelle schreiben, DB's sind in der Regel sehr schnell und können einiges vertragen.
 
Zurück
Oben Unten