INSERT ... ON DUPLIKATE KEY
0 0 
dedlfix
0 0 dedlfix
0 0 
Matthias Apsel
0 Matthias Apsel
0
INSERT ... ON DUPLIKATE KEY
MudGuardHallo Forum,
ich bin incht ganz sicher, dass ich den "INSERT ... ON DUPLIKATE KEY" - Kontext richtig verstehe. Jedenfalls macht er an einer Stelle nicht das, was ich erwartet hatte:
insert into tabelle (
spalte1,
spalte2,
spalte3
) VALUES (
NULL,
"my_string",
my_id
)
ON DUPLICATE KEY UPDATE spalte3=spalte3
Ich hätte erwartet, dass so lange ein "insert" getätigt wird, solange in spalte3 keine "my_id" eingesetzt werden soll, die es bereits gibt. Und wenn es sie gäbe, soll dieser Eintrag upgedatet werden.
In meinem vorliegenden Fall wird aber immer ein insert gemacht.
Kann mir nochmal einer erklären, was ich ggf. da nicht richtig verstehe?
Lukas
-
Kann mir nochmal einer erklären, was ich ggf. da nicht richtig verstehe?
... oder muß, damit das funktioniert, die Spalte3 "unique" sein, damit überhaupt ein 1062er generiert wird?
Lukas
-
Tach!
Kann mir nochmal einer erklären, was ich ggf. da nicht richtig verstehe?
... oder muß, damit das funktioniert, die Spalte3 "unique" sein, damit überhaupt ein 1062er generiert wird?
Na klar. Das DBMS hat keine Lust, jedes Mal einen Full-Table-Scan zu machen, um doppelte Einträge in einer unsortierten Menge zu finden. Da muss schon ein Index her, in dem Fall ein eindeutiger.
dedlfix.
-
Hi dedlfix,
Na klar. Das DBMS hat keine Lust, jedes Mal einen Full-Table-Scan zu machen, um doppelte Einträge in einer unsortierten Menge zu finden. Da muss schon ein Index her, in dem Fall ein eindeutiger.
Das ist sowohl verständlich als auch ungünstig für mich. Hintergrund: Die Tabelle, um die es geht, hat in spalte3 leider eine ID, die einmal oder zweimal auftreten kann. Wenn sie doppelt auftritt, findet die Unterscheidung dann in Spalte7 statt. Soll heißen, ich müsste einen Unique Index setzen, der sich aus der Kombination aus Spalte3+Spalte7 ergibt. Geht sowas?
Lukas
-
Tach!
[...] ich müsste einen Unique Index setzen, der sich aus der Kombination aus Spalte3+Spalte7 ergibt. Geht sowas?
Welches positive Ergebnis hat dein Versuch ergeben?
dedlfix.
-
Hi,
Welches positive Ergebnis hat dein Versuch ergeben?
Na, ich habs mir einfach gemacht. Da ich nicht wußte, ob die "unique-Kombi-aus-2-spalten" geht und es außerdem auch schwer lesbar wäre, habe ich der Tabelle eine zusätzliche Spalte gegeben, in die ich gleich den "Kombiwert" eintrage und habe diese Spalte auf unique indiziert.
Das hatte dann auch den Vorteil, dass ich gleich die 3. Spalte, die ich zusätlich zur 2-Spalten-Kombi unique hätte indizieren müssen (das hatte ich in meinem Auusgangsposting noch nciht erwähnt, weil es mir klar war), mit in diese Zusatzspalte einbeziehen konnte.
Jetzt habe ich eine Tabelle mit lediglich einer unique-Spalte, an der sich die Query orientiert. Und die Query selber verstehe ich jetzt auch (da gabs im Vorfeld auch noch kleine Probleme bei mir, die jetzt ausgeräumt sind).
Danke für die Hilfestellung,
Lukas
-
Hallo Lukas .,
Na, ich habs mir einfach gemacht. Da ich nicht wußte, ob die "unique-Kombi-aus-2-spalten" geht und es außerdem auch schwer lesbar wäre, habe ich der Tabelle eine zusätzliche Spalte gegeben, in die ich gleich den "Kombiwert" eintrage und habe diese Spalte auf unique indiziert.
Zusammengesetzte Primärschlüssel sind eine Grundlage für die Arbeit mit Datenbanken. Es ist nicht sinnvoll, eine solche Redundanz zu erzeugen.
Bis demnächst
Matthias-
Hallo Matthias Apsel,
Zusammengesetzte Primärschlüssel
Bis demnächst
Matthias -
Hi,
Zusammengesetzte Primärschlüssel sind eine Grundlage für die Arbeit mit Datenbanken. Es ist nicht sinnvoll, eine solche Redundanz zu erzeugen.
Das kannst Du so undifferenziert von außen nicht sagen. Es gibt Redundanzen, die durchaus Sinn machen. Es kommt immer auf die Betrachtungsweise an.
In diesem Fall z.b. hätte ich mehrere Indexe auf mehrere Spalten setzen müssen. Selbst wenn die DB damit wunderbar klar gekommen wäre, hätte ich es bei eventuellen Wartungsarbeiten viel schwerer, die Dinge auf einen Blick zu erfassen oder auch zu sortieren. Da es sich ohnehin um flüchtige Daten handelt, spielt die Datenmenge eine untergeordnete Rolle. Insofern ist es durchaus sinnvoll, den Vorteil der reduntanten Daten auszunutzen und dem Nachteil der durch Redundanz erhöhten Datenmenge überzuordnen.
Lukas
-
Hallo Lukas .,
Das kannst Du so undifferenziert von außen nicht sagen.
Das mag sein. Ausgehend von deinem hier genannten Beispiel aber schon.
Es gibt Redundanzen, die durchaus Sinn machen.
Ja. Zum Beispiel ein zweites Netzteil an einem Server oder ein RAID ;-)
In diesem Fall z.b. hätte ich mehrere Indexe auf mehrere Spalten setzen müssen.
Nein. (Jedenfalls nicht in diesem wahrscheinlich vereinfachten Beispiel) Ein Index über mehrere Spalten.
Selbst wenn die DB damit wunderbar klar gekommen wäre, hätte ich es bei eventuellen Wartungsarbeiten viel schwerer, die Dinge auf einen Blick zu erfassen oder auch zu sortieren.
Wartbarkeit ist auch immer ein wichtiges Argument.
Da es sich ohnehin um flüchtige Daten handelt, spielt die Datenmenge eine untergeordnete Rolle. Insofern ist es durchaus sinnvoll, den Vorteil der reduntanten Daten auszunutzen und dem Nachteil der durch Redundanz erhöhten Datenmenge überzuordnen.
Bis demnächst
Matthias -
Hi,
Zusammengesetzte Primärschlüssel sind eine Grundlage für die Arbeit mit Datenbanken. Es ist nicht sinnvoll, eine solche Redundanz zu erzeugen.
Es gibt Redundanzen, die durchaus Sinn machen. Es kommt immer auf die Betrachtungsweise an.
Insofern ist es durchaus sinnvoll, den Vorteil der reduntanten Daten auszunutzen und dem Nachteil der durch Redundanz erhöhten Datenmenge überzuordnen.
Das Haupt-Problem bei Redundanzen ist nicht der um wenige Byte erhöhte Speicherbedarf, sondern, daß die Werte der Einzel-Spalten und der Wert der Sammelspalte auseinanderlaufen, weil bei irgendwelchen Updates vergessen wird, beide Stellen zu ändern.
cu, Andreas a/k/a MudGuard
-
Hallo MudGuard,
Das Haupt-Problem bei Redundanzen ist nicht der um wenige Byte erhöhte Speicherbedarf, sondern, daß die Werte der Einzel-Spalten und der Wert der Sammelspalte auseinanderlaufen, weil bei irgendwelchen Updates vergessen wird, beide Stellen zu ändern.
Dafür gibt es Trigger.
Ob die Redundanz hier Sinn macht können wir von aussen vermutlich nicht entscheiden, aber anhand des hier propagierten Beispiels halte ich sie auch nicht für angebracht; ein combined index halte ich hier auch für sinnvoller.
LG,
CK
-
-
-
-
-
-
-
-