INSERT ... ON DUPLICATE KEY UPDATE bearbeitet von Raketenwilli 29.10.2022 17:45 > Moin,> > > Die ID wird es mehrmals in der Tabelle geben. Es ist quasi die Objekt-ID und sie wird für die jeweiligen Benutzer-ID manipuliert. Ich habe das der Einfachheit halber aber bei meinem ursprünglichen Beitrag nicht mit einbezogen.> > Aber die Kombination aus Benutzer-ID und Objekt-ID ist eindeutig, oder? Das klappt dann trotzdem, im INSERT-Query müssen halt alle drei Felder genannt werden.Jepp. Und der genannte „UNIQUE Constraint“ muss sich dann über die Spalten erstecken, die in jeglicher Kombination maximal einmal auftauchen sollen.@@borisbaer~~~SQLALTER TABLE `tab` ( UNIQUE KEY ( `UserID`, `ObjectID` ))~~~Die Benennung eines Feldes mit „ID“, welches keine echte ID ist, ist höchst unglücklich. Das wird zu Fehlern führen, weil es im sachlichen Zusammenhang einfach mal keine ID ist, aber jeder wegen des Bezeichners denkt, es sei eine solche - und also sei jede einzigartig…*„Ich lösche mal fix **einen** Datensatz:“*~~~SQLDELETE FROM `tab` WHERE ID=121;346967 Zeilen gelöscht.~~~*„Oh.“*
INSERT ... ON DUPLICATE KEY UPDATE bearbeitet von Raketenwilli 29.10.2022 17:50 > Moin,> > > Die ID wird es mehrmals in der Tabelle geben. Es ist quasi die Objekt-ID und sie wird für die jeweiligen Benutzer-ID manipuliert. Ich habe das der Einfachheit halber aber bei meinem ursprünglichen Beitrag nicht mit einbezogen.> > Aber die Kombination aus Benutzer-ID und Objekt-ID ist eindeutig, oder? Das klappt dann trotzdem, im INSERT-Query müssen halt alle drei Felder genannt werden.Jepp. Und der genannte „UNIQUE Constraint“ muss sich dann über die Spalten erstecken, die in jeglicher Kombination maximal einmal auftauchen sollen.@@borisbaer~~~SQLALTER TABLE `tab` ( UNIQUE KEY ( `UserID`, `ObjectID` ))~~~Die Benennung eines Feldes mit „ID“, welches keine echte ID ist höchst unglücklich. Das wird zu Fehlern führen, weil es im sachlichen Zusammenhang einfach mal keine ID ist, aber jeder wegen des Bezeichners denkt, es sei eine solche - und also sei jede einzigartig…*„Ich lösche mal fix **einen** Datensatz:“*~~~SQLDELETE FROM `tab` WHERE ID=121;346967 Zeilen gelöscht.~~~*„Oh.“*
INSERT ... ON DUPLICATE KEY UPDATE bearbeitet von Raketenwilli 29.10.2022 17:49 > Moin,> > > Die ID wird es mehrmals in der Tabelle geben. Es ist quasi die Objekt-ID und sie wird für die jeweiligen Benutzer-ID manipuliert. Ich habe das der Einfachheit halber aber bei meinem ursprünglichen Beitrag nicht mit einbezogen.> > Aber die Kombination aus Benutzer-ID und Objekt-ID ist eindeutig, oder? Das klappt dann trotzdem, im INSERT-Query müssen halt alle drei Felder genannt werden.Jepp. Und der genannte „UNIQUE Constraint“ muss sich dann über die Spalten erstecken, die in jeglichrer Kombination nurmaximal einmal auftauchen sollen.@@borisbaer~~~SQLALTER TABLE `tab` ( UNIQUE ( `UserID`, `ObjectID` ))~~~Die Benennung eines Feldes mit „ID“, welches keine echte ID ist höchst unglücklich. Das wird zu Fehlern führen, weil es im sachlichen Zusammenhang einfach mal keine ID ist, aber jeder wegen des Bezeichners denkt, es sei eine solche - und also sei jede einzigartig…*„Ich lösche mal fix **einen** Datensatz:“*~~~SQLDELETE FROM `tab` WHERE ID=121;346967 Zeilen gelöscht.~~~*„Oh.“*
INSERT ... ON DUPLICATE KEY UPDATE bearbeitet von Raketenwilli 29.10.2022 17:47 > Moin,> > > Die ID wird es mehrmals in der Tabelle geben. Es ist quasi die Objekt-ID und sie wird für die jeweiligen Benutzer-ID manipuliert. Ich habe das der Einfachheit halber aber bei meinem ursprünglichen Beitrag nicht mit einbezogen.> > Aber die Kombination aus Benutzer-ID und Objekt-ID ist eindeutig, oder? Das klappt dann trotzdem, im INSERT-Query müssen halt alle drei Felder genannt werden.Jepp. Und der genannte „UNIQUE Constraint“ muss sich dann über die Spalten erstecken, die ihrer Kombination nur einmal auftauchen sollen.@@borisbaer~~~SQLALTER TABLE `tab` ( UNIQUE ( `UserID`, `ObjectID` ))~~~Die Benennung eines Feldes mit „ID“, welches keine echte ID ist höchst unglücklich. Das wird zu Fehlern führen, weil es im sachlichen Zusammenhang einfach mal keine ID ist, aber jeder wegen des Bezeichners denkt, es sei eine solche - und also sei jede einzigartig…*„Ich lösche mal fix **einen** Datensatz:“*~~~SQLDELETE fromFROM `tab` wehreWHERE ID=121;346967 Zeilen gelöscht.~~~*„Oh.“*
INSERT ... ON DUPLICATE KEY UPDATE bearbeitet von Raketenwilli 29.10.2022 17:46 > Moin, > > > Die ID wird es mehrmals in der Tabelle geben. Es ist quasi die Objekt-ID und sie wird für die jeweiligen Benutzer-ID manipuliert. Ich habe das der Einfachheit halber aber bei meinem ursprünglichen Beitrag nicht mit einbezogen. > > Aber die Kombination aus Benutzer-ID und Objekt-ID ist eindeutig, oder? Das klappt dann trotzdem, im INSERT-Query müssen halt alle drei Felder genannt werden. Jepp. Und der genannte „UNIQUE Constraint“ muss sich dann über die Spalten erstecken, die ihrer Kombination nur einmal auftauchen sollen. @@borisbaer ~~~SQL ALTER TABLE `tab` ( UNIQUE ( `UserID`, `ObjectID` ) ) ~~~ Die Benennung eines Feldes mit „ID“, welches keine echte ID ist höchst unglücklich. Das wird zu Fehlern führen, weil es im sachlichen Zusammenhang einfach mal keine ID ist, aber jeder wegen des Bezeichners denkt, es sei eine solche - und also sei jede einzigartig… „Ich lösche mal fix **einen** Datensatz:“ ~~~SQL DELETE from `tab` wehre ID=121; 346967 Zeilen gelöscht. ~~~
nicht angemeldet nicht angemeldet
