nicht angemeldet
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.