"Insert Into ON Duplicate Key Update" auch ohne Key möglich?

[Falk Prüfer]

Hm, nur mal so für unbedarfte, welcher Vorteil ergibt sich zwischen int(2) und int(11)?

Hmm, naja, wohl eher nur ein psychologischer . Einen wirklichen Vorteil gibt es wahrscheinlich nicht. Ein INT bleibt ein INTEGER und damit eine vorzeichenbehaftete 4Byte Ganzzahl. Mein Einwurf lag wohl eher daran, dass ich Felddefinitionen eben auch immer auf Plausibilität prüfe und da war der INT(11) eben etwas fehl am Platze, auch wenn es rein technisch natürlich keinen Unterschied macht. Für einen evtl. "Vorteil" wäre dann wohl eher ein UNSINGNED TINYINT angebracht.

@hausl78 bzgl. CHAR vs. VARCHAR:
Wenn ein CHAR gegenüber einem VARCHAR einen Performancevorteil haben sollte (der wahrscheinlich gegenüber manch anderen Dingen so marginal ist, dass man ihn vernachlässigen kann), dann sicherlich bei häufigen Änderungen eines Feldes. Wenn also ständig neue Strings mit jeweils anderer Länge per Update geschrieben werden, dann hat CHAR sicherlich einen Vorteil, da hier immer der gleiche Platz belegt wird, während es bei VARCHAR zu einer Defragmentierung der Daten kommen kann.
Da sowas wie ein Nickname wohl eher selten wenn überhaupt geändert wird, nimmst du hier mit dem CHAR einige Nachteile für einen defacto nicht vorhandenen Vorteil in Kauf.

Gruß Falk

[hausl78]

@hausl78 bzgl. CHAR vs. VARCHAR:
Wenn ein CHAR gegenüber einem VARCHAR einen Performancevorteil haben sollte (der wahrscheinlich gegenüber manch anderen Dingen so marginal ist, dass man ihn vernachlässigen kann), dann sicherlich bei häufigen Änderungen eines Feldes. Wenn also ständig neue Strings mit jeweils anderer Länge per Update geschrieben werden, dann hat CHAR sicherlich einen Vorteil, da hier immer der gleiche Platz belegt wird, während es bei VARCHAR zu einer Defragmentierung der Daten kommen kann.
Da sowas wie ein Nickname wohl eher selten wenn überhaupt geändert wird, nimmst du hier mit dem CHAR einige Nachteile für einen defacto nicht vorhandenen Vorteil in Kauf.
Gruß Falk

Ah, ok na dann wird der ein VARCHAR ;-)

Darf ich weiterführend hier auch zum Skript was fragen?

Ich versuche das Update:
UPDATE tabTipps SET TippTor1='''' WHERE SpielIDRef=4061 AND Nickname='Franzi'
((eben sehe ich das ich hier wohl NULL statt '' verwenden sollte :-))

Erhalte dann das nichts upgedatet wurde:
mysql_affected_rows() -> 0

Versuche dann ein INSERT:
INSERT INTO tabTipps (Nickname, SpielIDRef, TippTor1) VALUES ('Franzi', 4061, '')

Bekommen dann Fehler das schon da ist (Ich habe einen unique constraint(Nickname, SpielIDRef)
Duplicate entry 'Franzi-4061' for key 'NicknameUndSpielIDRef'/---------

Da beim UPDATE eine 0 zurückkommt mache in ein INSERT und dann Fehler weil das Satz schon da ist. Ich dachte UPDATE gibt immer 1 zurück wenn der Satz da ist aber das Ding ist schlau und gibt "nur" zurück ob was geändert wurde und das hat es ja nicht, weil es ncihts zu ändern gab, weil der Satz schon 1:1 da ist.. *grrr*



Juergen

[hausl78]

Hat sich soweit mal erledigt, aber eine Frage noch.. Wenn ich einen Schlüssel mittels

ALTER TABLE <tabelle> ADD CONSTRAINT UNIQUE KEY <eindeutiger_Name> (User, SpielID)

definiere, dann kann ich auch das "INSERT ... ON KEY EXISTS UPDATE" verwenden, auch wenn mein Schlüssel in witklichkeit zwei Spalten sind, oder?

Danke!

[Falk Prüfer]

Ja, genau dafür ist es da und genau deshalb habe ich dir epmfohlen diesen Schlüssel anzulegen.

[hausl78]

Super, danke vielmals!

[hausl78]

// EDIT:

So gehts:

INSERT INTO tabTipps
SET Nickname = 'Karli', SpielIDRef = 4064, TippTor1 = 3
ON DUPLICATE KEY UPDATE TippTor1 = 3;

Wenn ich morgen mehr Zeit hab dann prüf ich das noch im Detail aber es wird upgedated und es gibt keinen Syntaxfehler... ;-)

Juergen

[hausl78]

So, ich wieder...

Es scheint tatsächlich genau so zu funktionieren wie es soll, vielen dank dafür, wieder mal ne Menge gelernt..

Danke!!!