Zusammenfassen von fuenf "UPDATE"s

Morgen allesamt,

ich habe hier insgesamt 5 UPDATE-Anweisungen, die ich gerne zu eienr
zusammenfassen wuerde.

Erstmal die Ausgangssituation:

---8<--snip-->8---

UPDATE `uwc3`.`uwc3_enh`
SET `uwc3_enh`.`att1` = '$attrib0',
`uwc3_enh`.`att2` = '$attrib1',
`uwc3_enh`.`att3` = '$attrib2',
`uwc3_enh`.`att4` = '$attrib3',
`uwc3_enh`.`att5` = '$attrib4'
`uwc3_enh`.`res1` = '$res0',
`uwc3_enh`.`res2` = '$res1',
`uwc3_enh`.`res3` = '$res2',
`uwc3_enh`.`res4` = '$res3',
`uwc3_enh`.`res5` = '$res4'
WHERE `uwc3_enh`.`steamid` = '$steam_ID';

UPDATE `uwc3`.`uwc3_skills1`
SET `uwc3_skills1`.`skill1` = '$vamp',
`uwc3_skills1`.`skill2` = '$levi'
WHERE `uwc3_skills1`.`steamid` = "$steam_ID";

UPDATE `uwc3`.`uwc3_skills2`
SET `uwc3_skills2`.`skill11` = '$cstr',
`uwc3_skills2`.`skill12` = '$repa'
WHERE `uwc3_skills2`.`steamid` = "$steam_ID";

UPDATE `uwc3`.`uwc3_skills3`
SET `uwc3_skills3`.`skill21` = '$shad',
`uwc3_skills3`.`skill22` = '$enta'
WHERE `uwc3_skills3`.`steamid` = "$steam_ID";

UPDATE `uwc3`.`uwc3_skills4`
SET `uwc3_skills4`.`skill31` = '$fano',
`uwc3_skills4`.`skill32` = '$veng',
WHERE `uwc3_skills4`.`steamid` = "$steam_ID";

---8<--snap-->8---

Mein Versuch war dann folgender:

---8<--snip-->8---

UPDATE `uwc3`.`uwc3_enh`, `uwc3`.`uwc3_skills1`, `uwc3`.`uwc3_skills2`,
`uwc3`.`uwc3_skills3`, `uwc3`.`uwc3_skills4`,
SET `uwc3_enh`.`att1` = '$attrib0',
`uwc3_enh`.`att2` = '$attrib1',
`uwc3_enh`.`att3` = '$attrib2',
`uwc3_enh`.`att4` = '$attrib3',
`uwc3_enh`.`att5` = '$attrib4'
`uwc3_enh`.`res1` = '$res0',
`uwc3_enh`.`res2` = '$res1',
`uwc3_enh`.`res3` = '$res2',
`uwc3_enh`.`res4` = '$res3',
`uwc3_enh`.`res5` = '$res4',
`uwc3_skills1`.`skill1` = '$vamp',
`uwc3_skills1`.`skill2` = '$levi',
`uwc3_skills2`.`skill11` = '$cstr',
`uwc3_skills2`.`skill12` = '$repa',
`uwc3_skills3`.`skill21` = '$shad',
`uwc3_skills3`.`skill22` = '$enta',
`uwc3_skills4`.`skill31` = '$fano',
`uwc3_skills4`.`skill32` = '$veng'
WHERE `uwc3_enh`.`steamid` = "$steam_ID"
AND `uwc3_skills1`.`steamid` = "$steam_ID"
AND `uwc3_skills2`.`steamid` = "$steam_ID"
AND `uwc3_skills3`.`steamid` = "$steam_ID"
AND `uwc3_skills4`.`steamid` = "$steam_ID";

---8<--snap-->8---

Der war aber keineswegs von Erfolg gekroent.

Vielleicht kann mir ja jemand sagen, was ich falsch mache/falsch
verstanden habe. Danke!

Mit freundlichen Gruessen/Best Regards Oliver Beck

--
/"\ -ASCII-Ribbon-Campaign- |
\ / Against HTML Mail |
X | -- German GNU/Hurd documentation --
/ \ | - http://de-hurd-doc.berlios.de -

Re: Zusammenfassen von fuenf "UPDATE"s

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
http://a-kretschmer.de/pict4592.jpg

Re: Zusammenfassen von fuenf "UPDATE"s

Hi Andreas,

Am 2007-09-12, Andreas schrub:

> Was verstehst Du unter 'zusammenfassen'? IMHO kannst Du nicht mehrere
> Tabellen mit einmal updaten, du kannst das aber innerhalb einer
> Transaktion machen. Vorausgesetzt, Deine Storage-Engine unterstützt das.

Ich gehe davon aus, das am mysqld nichts weiter eingestellt wurde und als
Storage Engine nur InnoDB oder MySLQ AB in Frage kommt.

Mit freundlichen Gruessen/Best Regards Oliver Beck

--
/"\ -ASCII-Ribbon-Campaign- |
\ / Against HTML Mail |
X | -- German GNU/Hurd documentation --
/ \ | - http://de-hurd-doc.berlios.de -

Re: Zusammenfassen von fuenf "UPDATE"s

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Zusammenfassen von fuenf "UPDATE"s

Am 2007-09-12, Andreas schrub:

> Dunkel Deiner Worte Sinn. 'MySLQ AB' ist der Macher von MySQL, keine
> Storage Engine. Und am mysqld wirst Du kaum ein/ausschalten können, ob
> mit einem UPDATE 5 Tabellen bearbeitet werden können. Aber InnoDB ist
> TX-fähig.

Hmm ... schoene Fehlinterpretation, die ich da hatte ;) (bzgl. MySQL AB)

---Zitat Anfang---

You can also perform UPDATE operations covering multiple tables.
However, you cannot use ORDER BY or LIMIT with a multiple-table UPDATE.
The table_references clause lists the tables involved in the join. Its
syntax is described in Section 12.2.7.1, .JOIN Syntax.. Here is an
example:

UPDATE items,month SET items.price=month.price
WHERE items.id=month.id;

The preceding example shows an inner join that uses the comma operator,
but multiple-table UPDATE statements can use any type of join allowed in
SELECT statements, such as LEFT JOIN.

---Zitat Ende---

habe ich gerade in der MySQL-Doku gefunden (deren Suchmaske sehr
unuebersichtlich ist *grr*)

Also scheint es doch zu gehen ...

> Also: Dir ist bekannt, was eine Transaktion ist?

Noch nicht ... aber mal schauen, was es damit und mit den JOIN auf sich hat.


Mit freundlichen Gruessen/Best Regards Oliver Beck

--
/"\ -ASCII-Ribbon-Campaign- |
\ / Against HTML Mail |
X | -- German GNU/Hurd documentation --
/ \ | - http://de-hurd-doc.berlios.de -

Re: Zusammenfassen von fuenf "UPDATE"s

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Zusammenfassen von fuenf "UPDATE"s

Oliver Beck wrote:
> Also scheint es doch zu gehen ...

Klar geht es, aber die grosse Frage ist: Warum willst Du das unbedingt
machen? Du hast fuenf Tabellen upzudaten, die untereinander keinen Bezug
haben (d.h. Du benoetigst fuer Update von Tabelle a nicht einen Wert aus
Tabelle b), du schreibst lediglich in fuenf Tabellen, deren Eintraege
jeweils anhand von einem zufaelligerweise gleichbenannten Feld "steamid" (um
wieviele Sorten von Daempfen geht's denn da?) referenziert werden, extern
gewonnene Daten.

In diesem Fall sehe ich eigentlich keinen Nutzen, das mit einem einzigen
Update durchzuziehen. Wenn Du eventuell einen ROLLBACK brauchst, dann nutze
eine transaktionsunterstuetzende storage engine und stopf die fuenf Updates
in eine Transaktion.

Ansonsten garantiert Dir ein einziger UPDATE naemlich auch nicht, dass alles
oder nichts geaendert wurde:

| mysql> create table e1 (a integer not null, id integer not null);
| Query OK, 0 rows affected (0.01 sec)
|
| mysql> create table e2 (a integer not null, id integer not null);
| Query OK, 0 rows affected (0.01 sec)
|
| mysql> alter table e1 add unique index(a);
| Query OK, 0 rows affected (0.04 sec)
| Records: 0 Duplicates: 0 Warnings: 0
|
| mysql> insert into e1 values (1,1);
| Query OK, 1 row affected (0.02 sec)
|
| mysql> insert into e1 values (2,2);
| Query OK, 1 row affected (0.00 sec)
|
| mysql> insert into e2 values (1,1);
| Query OK, 1 row affected (0.00 sec)
|
| mysql> update e1,e2 set e1.a=2,e2.a=2 where e1.id=1 and e2.id=1;
| ERROR 1062 (23000): Duplicate entry '2' for key 1
| mysql> select * from e1;
| +---+----+
| | a | id |
| +---+----+
| | 1 | 1 |
| | 2 | 2 |
| +---+----+
| 2 rows in set (0.00 sec)
|
| mysql> select * from e2;
| +---+----+
| | a | id |
| +---+----+
| | 2 | 1 |
| +---+----+
| 1 row in set (0.00 sec)

Wie man sieht, der Query hat einen Fehler geworfen, weil eine Tabelle nicht
geupdated werden konnte, die andere wurde es aber durchaus veraendert.

Von daher: Ich sehe keinen Sinn, die fuenf UPDATEs kuenstlich in einen zu
kombinieren. Naja, ausser Du bist in einem sehr High-Performance-Umfeld und
musst round-trip-times zum Server sparen, dann mag eventuell eine stored
procedure fuer die Updates einen kleinen Vorteil bringen, aber ob der
ausschlaggebend ist?

Re: Zusammenfassen von fuenf "UPDATE"s

Am 2007-09-12, Sven schrub:
> Oliver Beck wrote:
>> Also scheint es doch zu gehen ...
>
> Klar geht es, aber die grosse Frage ist: Warum willst Du das unbedingt
> machen? Du hast fuenf Tabellen upzudaten, die untereinander keinen Bezug
> haben (d.h. Du benoetigst fuer Update von Tabelle a nicht einen Wert aus
> Tabelle b), du schreibst lediglich in fuenf Tabellen, deren Eintraege
> jeweils anhand von einem zufaelligerweise gleichbenannten Feld "steamid" (um
> wieviele Sorten von Daempfen geht's denn da?) referenziert werden, extern
> gewonnene Daten.

Es geht dabei um 0 Arten von Dampf ;)
Ich ahbe die DB-Struktur leider nicht entworfen ... ich werde mal ein
paar Worte dazu verlieren:

Es geht um eine Erweiterung fuer das Spiel CounterStrike. Im geneuaeren
das sogenannte 'Ultimate Warcraft 3'-Plugin. In diesem sammelt der
Spieler im Laufe der Zeit Punkte, die er dann wiederum fuer spezielle
Faehigkeiten einsetzen kann. Die Punkte werden halt in mehreren
MySQL-Tabellen gespeichert, die Dummerweise doch einen Bezug zueinander
haben. (auch wenn aus dem Design der Table heraus nicht ersichtlich)

Jeder Spieler hat also 40 Fahigkeiten. Diese sind in den vier Tables
'uwc3_skills1', 'uwc3_skills2', 'uwc3_skills3' und 'uwc3_skills4'
hinterlegt. Weiterhin gibt es noch Erweiterungen, um den Spieler
schneller oder wiederstandsfaehiger zu machen, dass er hoeher und weiter
springen kann, etc. Dies wird dann in der Tabelle 'uwc3_enh'
gespeichert. Alle Tabellen haben je ein Feld namens 'steamid'. Dieses
traegt eine eindeutige Zeichenfolge (ist zugleich in jeder Table der
PrimKey) und verknuepft quasi somit die 5 Tabellen.

Wenn ich also Veraenderungen an einer Tabelle mache, sind die anderen
u.U. fehlerbehaftet, da ich moeglicherweise zu viele Punkte vergeben
habe. (5 Punkte sollte aus einer Tabelle geloescht und in einer anderen
addiert werden)

Demnach denke ich, das da eine Transaktion wirklich die beste und
sicherste Variante ist, und werde diese auch so nutzen.


> Ansonsten garantiert Dir ein einziger UPDATE naemlich auch nicht, dass alles
> oder nichts geaendert wurde:
>
> (Hier koennte Ihr Beispiel stehen)
>
> Wie man sieht, der Query hat einen Fehler geworfen, weil eine Tabelle nicht
> geupdated werden konnte, die andere wurde es aber durchaus veraendert.

Wow ... das hatte ich so nicht erwartet. Ein weiterer Punkt, hier eine
Tansaktion zu nutzen.


> Von daher: Ich sehe keinen Sinn, die fuenf UPDATEs kuenstlich in einen zu
> kombinieren.

Ich auch nicht mehr ;)


> Naja, ausser Du bist in einem sehr High-Performance-Umfeld und
> musst round-trip-times zum Server sparen, dann mag eventuell eine stored
> procedure fuer die Updates einen kleinen Vorteil bringen, aber ob der
> ausschlaggebend ist?

Nein, kein HP-Umfeld ;)

Re: Zusammenfassen von fuenf "UPDATE"s

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Zusammenfassen von fuenf "UPDATE"s

Am 2007-09-12, Andreas schrub:

> Schon erstaunlich, daß Programmierer in solch einem Umfeld keine Ahnung
> von Transaktionen haben.

Schon erstaunlich, dass es Programmierier gibt, die das nicht von der
Pieke auf gelernt haben und das als Hobby betreiben und immer wieder
dazulernen ...

Re: Zusammenfassen von fuenf "UPDATE"s

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Zusammenfassen von fuenf "UPDATE"s

Oliver Beck schrieb:

> Am 2007-09-12, Sven schrub:
>
>> jeweils anhand von einem zufaelligerweise gleichbenannten Feld "steamid" (um
>
> Es geht um eine Erweiterung fuer das Spiel CounterStrike.

Damit wäre dann auch die "steamid" geklärt :-)

Gruß. Claus (selber einen Steam-Account besitzend)

Re: Zusammenfassen von fuenf "UPDATE"s

Oliver Beck schrieb:

> Am 2007-09-12, Andreas schrub:
>
>> Schon erstaunlich, daß Programmierer in solch einem Umfeld keine Ahnung
>> von Transaktionen haben.
>
> Schon erstaunlich, dass es Programmierier gibt, die das nicht von der
> Pieke auf gelernt haben und das als Hobby betreiben und immer wieder
> dazulernen ...

Lass Dich doch von Andreas nicht anmachen. Das bringt nichts.

Gruß. Claus

Re: Zusammenfassen von fuenf "UPDATE"s

Oliver Beck schrieb:
> Am 2007-09-12, Andreas schrub:
>
>> Schon erstaunlich, daß Programmierer in solch einem Umfeld keine Ahnung
>> von Transaktionen haben.
>
> Schon erstaunlich, dass es Programmierier gibt, die das nicht von der
> Pieke auf gelernt haben und das als Hobby betreiben und immer wieder
> dazulernen ...

Andreas ist perfekt geboren worden. Deswegen versucht er auch, uns arme
mySQL-Sünderlein zum einzig perfekten DBMS zu bekehren.


Amen,

Sebastian