Sollte man vor dem UPDATE prüfen, ob sich die Daten überhaupt geändert haben?

[klausschreiber]

Hallo,

ich habe bei meinem Projekt viele Formularfelder auf einer Seite, über die man Daten in einer Datenbank ändern kann. Jedes Formularfeld (bzw. jede Formularfeldgruppe; sind mehrere die zusammen gehören) stellen einen Datensatz in der Datenbank dar. Es werden natürlich nicht immer alle Formularfeldinhalte geändert.

Wenn nun ein UPDATE für einen Datensatz, der sich nicht geändert hat, an die DB geschickt wird, merkt das MySQL ja und führt keine Schreiboperationen durch.

Ist es trotzdem sinnvoll/üblich/performanter, die Datensätze vor der Ausgabe in einer Session zu speichern, um dann nach dem Absenden des Formulars über PHP zu prüfen, ob der User etwas am jeweiligen Datensatz geändert hat und nur bei Bedarf ein UPDATE an die Datenbank zu schicken?
Oder ist es üblich, einfach für jeden Datensatz ohne vorherige Überprüfung ein UPDATE an die DB zu senden?


Gruß,
Klaus

 

[theHacker]

Is halt gefährlich, wenn du sowas machst, weil der User ja z.B. zweimal dieselbe Seite offen haben kann. Ob sich das performance-technisch lohnt, dieses Risiko einzugehen, würd ich ehrlich gesagt bezweifeln.

 

[klausschreiber]

stimmt. An diesen Fall habe ich gar nicht gedacht. Dann lasse ich es glaub besser.

Danke,
Klaus

 

[Snyke]

Kann mir ehrlich gesagt nicht vorstellen dass ein check auf PHP ebene performanter sein soll als ein lookup und compare in mysql.

 

[klausschreiber]

ok, danke. Ich wusste nicht, wie schnell MySQL ist, wenn keine Daten geändert werden müssen. Wenn die Überprüfung in PHP unter Umständen eh langsamer ist, dann ist die Vorgehensweise ja eindeutig. Werde dann einfach jedes mal ein UPDATE senden.


Mal noch eine 2.Frage, die auch irgendwie dazu passt, weil es um die gleiche Abfrage geht:
Ich habe 2 Tabellen:
Tabelle 1

table1_id|user_id|verschiedene Daten
1|4|xxxxx
2|6|xxxxx

Tabelle 2

table2_id|andere Daten|table1_id
1|xxxxx|1
2|xxxxx|1
3|xxxxx|2
4|xxxxx|2
5|xxxxx|2

Wie ihr seht, ist zwischen den tabellen eine 1:n Beziehung. Jeder Datensatz in Tabelle 1 hat meistens so 1-4 Datensätze in Tabelle 2. Bei einem UPDATE muss ich ja auch sicherstellen, dass der User nur seine eigenen Datensätze ändert und nicht Fremde, indem er an den POST-Daten rumdoktert.

Da gäbe es ja nun mehrere Möglichkeiten, dies sicherzustellen:

Möglichkeit 1:
Es wird zuerst per SELECT geprüft, ob der Datensatz dem User gehört.
=> ist wohl die schlechteste Möglichkeit, weil immer 2 Abfragen (1x SELECT, 1x UPDATE notwendig ist)

Möglichkeit 2:
Ein JOIN von Tabelle 1 und Tabelle 2 und an die Abfrage ein "WHERE user_id = ..." drannhängen.
=> Vorteil:
- Der Datensatz in Tabelle 1 und Tabelle 2 wird in einem Aufwasch aktualisiert. Es reicht also eine Abfrage für beide Tabellen zusammen.
=> Nachteile:
- Gehören zu einem Datensatz in Tabelle 1 mehrere Datensätze in Tabelle 2, wird bei jeder Abfrage ein JOIN gemacht, auch wenn der zugehörige Datensatz in Tabelle 1 bereits aktualisiert wurde.
- Wenn per AJAX eine Änderung an einem Datensatz in Tabelle 2 gemacht wird (bei AJAX werden ja wirklich nur geänderte Daten übertragen), muss trotzdem ein JOIN mit Tabelle 1 gemacht werden, um überprüfen zu können, ob der User an diesem Datensatz etwas ändern darf.

Möglichkeit 3:
Die user_id wird auch in Tabelle 2 gespeichert.
=> Vorteil:
- Es entfallen unnötige JOIN's
=> Nachteile:
- doppelte Speicherung der user_id
- für den Datensatz in Taabelle 1 ist ein extra UPDATE notwendig. Gehört nur 1 Datensatz von Tabelle 2 zum entsprechenden Datensatz der Tabelle 1, sind trotzdem 2 UPDATE's notwendig, weil Tabelle 1 und 2 ja nicht gejoint sind.

Welche der Möglichkeiten ist die Beste? Ich habe auch keine Ahnung, wieviel Ressourcen ein extra UPDATE im Vergleich zu einem JOIN mehr verbraucht?

Ist in Anbetracht der Tatsache, dass ein Datensatz in Tabelle 1 meist eher wenig referenzierende Datensätze in Tabelle 2 hat, die Variante 2 mit dem JOIN am besten?

Gruß,
Klaus

 

[Sebmaster]

Ooooder man macht in der WHERE-Klausel nen Subselect
Wobei ich mich frage, ob ein Subselect schneller ist als ein JOIN

 

[ice-breaker]

Is halt gefährlich, wenn du sowas machst, weil der User ja z.B. zweimal dieselbe Seite offen haben kann. Ob sich das performance-technisch lohnt, dieses Risiko einzugehen, würd ich ehrlich gesagt bezweifeln.

aber gerade aus diesem Grund wäre es doch interessant
Nehmen wir an ich baue ein Wiki, und speicher einfach munter die neue Seite ab, dann überschreibe ich eine Änderung, die jemand gemacht hat, während ich an dem Text gearbeitet habe.
Da sollte es am besten prüfen, ob jemand vorher etwas geändert hat und mich warnen.

Ooooder man macht in der WHERE-Klausel nen Subselect
Wobei ich mich frage, ob ein Subselect schneller ist als ein JOIN

Ist das nicht von Fall zu Fall abhängig?
Dadurch dass viele Subselects von MySQL wieder in Joins umgewandelt werden (weil der Subselect-Optimizer noch in den Kinderschuhen steckt) würde ich mich da keine allgemeine Aussage treffen

 

[klausschreiber]

ok, danke euch Beiden. Wenn ein Subselect sowieso oft in einen Join umgewandelt wird, kann ich ja erstmal einen Join verwenden.

Vielleicht ist es ja eh irrelevant, weil sich nur ein paar fehlgeleitete User dorthin verirren. Und wenn das Pojekt gut läuft, kann ich dann ja immer noch Tests durchführen und diese kleinen Dinge optimieren.


Gruß,
Klaus