nicht angemeldet
MySQL update einer indizierten Tabelle
Tach zusammen.
3 MySQL-Tabellen
Tab1:
int id
...Daten
Tab2:
int id
varchar(40) suchwort INDEX
Tab1_Tab2elle3:
int id
int id_Tabelle1
int id_Tabelle2
also eine m:n-Beziehung zwischen Tab1 und Tab2.
Wenn in Tab1 ein neuer DS hinzukommt, kommen auch ihm zugeordnete Suchworte dazu - teils bereits in Tab2 vorhanden, teils neu.
Würdet Ihr erst per "select * from Tab2" für jedes einzelne neue Suchwort ermitteln ob es das Suchwort bereits gibt um es nur im Falle eines Nichtvorhandenseins in Tab2 per "insert..." zu speichern, oder würdet Ihr das direkt ohne "select" und "insert" mit "replace ..." erledigen, da die Suchworte in Tab2 indiziert sind?
Was geht wohl schneller, wenn mir mal von einem Datenvolumen von Tab1->200.000, Tab2->400.000, Tab3->4.000.000 ausgehen?
Klar, was ich meine?
Gruß vom foomaker
--
Natürlich glaube ich an die Existenz von Ausserirdischen. Schliesslich gibt es ja auch das PERFEKTE SCRIPT.
Natürlich glaube ich an die Existenz von Ausserirdischen. Schliesslich gibt es ja auch das PERFEKTE SCRIPT.
-
Hallo,
Würdet Ihr erst per "select * from Tab2" für jedes einzelne neue Suchwort ermitteln ob es das Suchwort bereits gibt um es nur im Falle eines Nichtvorhandenseins in Tab2 per "insert..." zu speichern,
Nein.
oder würdet Ihr das direkt ohne "select"
Ja.
und "insert" mit "replace ..." erledigen, da die Suchworte in Tab2 indiziert sind?
Was meinst Du damit? Ich vermute "nein".
Was geht wohl schneller, wenn mir mal von einem Datenvolumen von Tab1->200.000, Tab2->400.000, Tab3->4.000.000 ausgehen?
INSERT in Tabelle 2 vornehmen, Fehlermeldung wegen Schlüsselverletzung entsprechend behandeln, d.h. in diesem Fall das SELECT vornehmen.
Wunderbarer Anwendungsfall für Prepared Statements.
Freundliche Grüße
Vinzenz
-
Hallo Vinzenz
oder würdet Ihr das direkt ohne "select"
Ja.
und "insert" mit "replace ..." erledigen, da die Suchworte in Tab2 indiziert sind?
Was meinst Du damit? Ich vermute "nein".
Bei indizierten oder uniquen Werten kann man statt "insert" "replace" verwenden. "replace" überprüft erst, ob der _indizierte_ Wert bereits vorhanden ist. Falls ja, dann wird der vorhandene DS ersetzt. Im anderen Fall wird ein neuer DS eingefügt.
Was geht wohl schneller, wenn mir mal von einem Datenvolumen von Tab1->200.000, Tab2->400.000, Tab3->4.000.000 ausgehen?
INSERT in Tabelle 2 vornehmen, Fehlermeldung wegen Schlüsselverletzung entsprechend behandeln, d.h. in diesem Fall das SELECT vornehmen.
Wunderbarer Anwendungsfall für Prepared Statements.
Inwiefern?
Gruß, Carsten
--
Natürlich glaube ich an die Existenz von Ausserirdischen. Schliesslich gibt es ja auch das PERFEKTE SCRIPT.-
Hallo Carsten,
und "insert" mit "replace ..." erledigen, da die Suchworte in Tab2 indiziert sind?
Was meinst Du damit? Ich vermute "nein".
Bei indizierten oder uniquen Werten kann man statt "insert" "replace" verwenden. "replace" überprüft erst, ob der _indizierte_ Wert bereits vorhanden ist. Falls ja, dann wird der vorhandene DS ersetzt. Im anderen Fall wird ein neuer DS eingefügt.
das kannst Du nicht wollen! Es bedeutet, dass das Suchwort bereits vorhanden ist. Es bedeutet, dass mit an Sicherheit grenzender Wahrscheinlichkeit, dieses Suchwort mit Datensätze(n) in Tabelle 1 über Tabelle 3 verknüpft ist.
REPLACE löscht den Datensatz und legt ihn dann mit den Standardwerten neu an. Da Du die id nicht kennst, wird eine neue angelegt - ich gehe davon aus, dass Du Autoincrement-Werte verwendest. Du kannst auf den alten Wert jedoch nicht zurückgreifen, so dass Du kein Update für die anderen Datensätze durchführen kannst.
Aus diesem Grund folgt: Du willst REPLACE *NICHT* verwenden!
Du führst ein INSERT durch. Gelingt es, so hast Du die neue ID über LAST_INSERT_ID(). Schlägt es fehl, so ermittelst Du mit einem SELECT die zugehörige ID.
Was geht wohl schneller, wenn mir mal von einem Datenvolumen von Tab1->200.000, Tab2->400.000, Tab3->4.000.000 ausgehen?
INSERT in Tabelle 2 vornehmen, Fehlermeldung wegen Schlüsselverletzung entsprechend behandeln, d.h. in diesem Fall das SELECT vornehmen.
Wunderbarer Anwendungsfall für Prepared Statements.
Inwiefern?
weil es immer wieder das gleiche Statement ist, das ausgeführt wird - nur mit anderen Werten. Somit entfällt das Parsen der Query (und Du hast den angenehmen Nebeneffekt, dass Du Dich nicht um das Maskieren der Werte kümmern musst).
Freundliche Grüße
Vinzenz
-
-