2 Datensätze ändern => 2 SQLs?

[Meat]

Hallo zusammen.

angenommen ich habe folgende Tabellkonstellation:

id | name       | bemerkung
-----------------------------
1  | schneider  | a
2  | maier      | b

Und möchte durch _einen einzigen_ SQL-Befehl folgende Tabellekonstellation erhalten:

id | name           | bemerkung
-----------------------------
1  | schneiderlein  | c
2  | mayer          | d

Wie muss mein SQL lauten?
Ich möchte wirklich nur einen einzigen SQL dazu benutzen. Geht das oder brauch ich wirklich zwei SQLs?

MfG
Meat

PS: Wie der Befehl lautet, um einen Datensatz zu ändern, ist mir klar.

[wahsaga]

hi,

Wie muss mein SQL lauten?
Ich möchte wirklich nur einen einzigen SQL dazu benutzen. Geht das oder brauch ich wirklich zwei SQLs?

Das ginge m.E. höchstens auf diesen Spezialfall zugeschnitten, aber keineswegs so, dass das Statement für allgemeinere Fälle tauglich wäre.

Warum willst du denn keine zwei Updates machen?

gruß,
wahsaga

[Vinzenz Mai]

Hallo

id | name       | bemerkung

1  | schneider  | a
2  | maier      | b

Und möchte durch _einen einzigen_ SQL-Befehl folgende Tabellekonstellation erhalten:

id | name           | bemerkung

1  | schneiderlein  | c
2  | mayer          | d

Wie muss mein SQL lauten?

Konstruiere Dir eine entsprechend ellenlange CASE-WHEN-Konstruktion. Das ist nicht sinnvoll, aber es sollte gehen, wenn Dein uns unbekanntes Datenbankmanagementsystem (DBMS) CASE-WHEN unterstützt.

Ich möchte wirklich nur einen einzigen SQL dazu benutzen. Geht das oder brauch ich wirklich zwei SQLs?

Es erscheint mir wenig sinnvoll, es in einer einzigen SQL-Anweisung unterbringen zu wollen. Zwei getrennte UPDATE-Statements sind wunderbar einfach, leicht nachzuvollziehen, geht immer. Das ist das, was man will. Das ist das, was man einsetzt.

Freundliche Grüße

Vinzenz

[Meat]

Okay, zur Aufklärung.

Ich habe eine User-Tabelle, mit den Feldern
u_id, u_name, u_password, u_permissions, u_type_permissions, u_last_login.
Für was die Felder gebraucht werden, erkennt man an ihren Namen. u_ steht für "user".

Ich bin in der Webapp, die ich gerade programmiere, selbstverständlich Admin. Ich gebe mir dort eine Liste aus, mit allen Usern und deren Daten, die in der Tabelle sind. Diese Daten kann ich auch in der selben Liste ändern.

Soweit hab ich das auch geschafft. Das Formular ist aufgebaut. Momentan sind 2 Testuser in der Tabelle angelegt. Unser Verein, für den ich das programmiere, hat 13 Mitglieder, sprich, die Tabelle hat später 13 Datensätze.

Angenommen, ich möchte jetzt mehreren Usern mehrere unterschiedliche permissions geben (Feld "u_permissions" und "u_type_permissions"), dann ändere ich in diesem Formular bei den gewünschten Usern die Felder ab.

In dem PHP-Script, das das Formular aufruft, prüfe ich dann auf eine Veränderung. Sobald auch nur eine einzige Veränderung gemacht wurde, wird die Variable $geaendert auf true gesetzt.
Da ich es mit meiner bisherigen Struktur und Planungsweise nicht verwirklichen kann, herauszufinden, _wo_ die Änderung passiert ist, muss ich eben alle Daten neu einspeisen.

Es sind also zwingend mehrere SQLs erforderlich, hab ich das so richtig verstanden?
Gut, ich denke, 13 Updates sind kein Problem, die halten den Server nicht lange auf. Ich denke aber in die Zukunft, in der wir mal 30 Mitglieder oder noch mehr haben werden.
Ich müsste dann eine Schleife aufrufen, die eben 13mal durchlaufen wird und 13 mal einen Datensatz ändert. Oder 30. Oder 100. Oder ....

MfG und Danke
Meat

[Ilja]

yo,

Es sind also zwingend mehrere SQLs erforderlich, hab ich das so richtig verstanden?

nein, nicht zwingend, das hast du falsch verstanden. aber es ist ratsam dass zu trennen, weil es keinen sind macht, es zusammen zu packen.

Ich müsste dann eine Schleife aufrufen, die eben 13mal durchlaufen wird und 13 mal einen Datensatz ändert. Oder 30. Oder 100. Oder ....

ganz schleche vorgehensweise, du solltest nur die datensätze in der datenbank updaten, die sich auch wirklich verändert haben. das würde ich schleunigst im code ändern.

Ilja

[King^Lully]

aber es ist ratsam dass zu trennen, weil es keinen sind macht, es zusammen zu packen.

Was mir an Euch Kleinschreibern wohl immer unklar bleiben wird, ist wie ihr qualitativ hochwertigen (Programm- ;)Code erstellen wollt, wenn es schon bei einfachen Tastendrücken massiv zu hapern scheint.

[King^Lully]

Angenommen, ich möchte jetzt mehreren Usern mehrere unterschiedliche permissions geben (Feld "u_permissions" und "u_type_permissions"), dann ändere ich in diesem Formular bei den gewünschten Usern die Felder ab.

Du hast ja letztlich Regelmengen erstellt, bspw. willst Du den Nutzern mit der ID 1,4,13 das Admin-Recht zugestehen, anderen Nutzern das Guest-Recht und anderen sagen wir mal das Power User-Recht (vermutlich gibts noch "normale Nutzer" ;).

Also, vier Rechtezuweisungsregeln heisst 4 SQLs, keinesfalls 13 SQLs, wenn es 13 Nutzer gibt. Packe die IDs in die WHERE-Klausel, wie sich das gehört.
Höre nicht auf Ratschläge die darauf hinauslaufen, alles in ein SQL zu packen, das ist zwar möglich, aber wie Vinnie anmerkt nicht sinnvoll (es sei denn Du möchtest die Ausführung von zwei SQLs "transaktional" zusammenpacken, aber das steht hier absolut nicht zur Debatte).

Da ich es mit meiner bisherigen Struktur und Planungsweise nicht verwirklichen kann, herauszufinden, _wo_ die Änderung passiert ist, muss ich eben alle Daten neu einspeisen.

Häh? Du kriegst doch Rückmeldungen vom Datenserver. Diese auswerten.

Es sind also zwingend mehrere SQLs erforderlich, hab ich das so richtig verstanden?

Nein, aber Du solltest mehrere SQLs absetzen.

Gut, ich denke, 13 Updates sind kein Problem, die halten den Server nicht lange auf. Ich denke aber in die Zukunft, in der wir mal 30 Mitglieder oder noch mehr haben werden.
Ich müsste dann eine Schleife aufrufen, die eben 13mal durchlaufen wird und 13 mal einen Datensatz ändert. Oder 30. Oder 100. Oder ....

SQL ist mengenorientiert, ein Gerubbel mit Schleifen und so läuft auf Missbrauch hinaus.