Re: UPDATE mit rekursivem SELECT
- From: Dieter Noeth <dnoeth@xxxxxx>
- Date: Sat, 25 Jul 2009 21:59:34 +0200
Michael Schuerig wrote:
CREATE TABLE numbers (
id serial PRIMARY KEY,
value real NOT NULL,
parent_id int REFERENCES numbers(id)
);
UPDATE numbers AS n SET value =
(SELECT AVG(children.value)
FROM numbers AS children WHERE children.parent_id = n.id);
Bei diesem UPDATE-Statement spielt die Reihenfolge der Auswertung eine Rolle. Wenn die neuen Werte einzeln berechnet und unmittelbar zugewiesen werden, gehen diese neuen Werte schon in die Berechnung der anschließend berechneten Werte ein.
Hä?
Du verwendest SQL, das arbeitet mengenorientiert und kennt keine Reihenfolge.
Wünschenswert wäre natürlich, wenn Abarbeitung in zwei Schritte getrennt würden, also zuerst Berechnung aller neuen Werte, dann deren Zuweisung.
Genau so arbeitet SQL.
Dieses Verhalten kann ich natürlich einfach erzwingen, indem ich die neuen Werte zunächst in ein temporäres Attribut schreibe und dieses im zweiten Schritt in value kopiere.
Das brauchst du nicht zu erzwingen, das ist so.
Sagt der SQL-Standard etwas darüber aus, welches Verhalten korrekt ist?
s.o.
Was tun die üblichen Verdächtigen (MySQL, PostgreSQL, Oracle, ...)?
Ich hoffe doch, das Richtige.
Wobei MySQL da aus der Reihe tanzt, das erlaubt so eine Abfrage gar nicht:
"Currently, you cannot update a table and select from the same table in a subquery."
Da geht nicht mal ein "set a=b, b=a" um a und b auszutauschen.
Dieter
.
- Follow-Ups:
- Re: UPDATE mit rekursivem SELECT
- From: Michael Schuerig
- Re: UPDATE mit rekursivem SELECT
- References:
- UPDATE mit rekursivem SELECT
- From: Michael Schuerig
- UPDATE mit rekursivem SELECT
- Prev by Date: UPDATE mit rekursivem SELECT
- Next by Date: Re: UPDATE mit rekursivem SELECT
- Previous by thread: UPDATE mit rekursivem SELECT
- Next by thread: Re: UPDATE mit rekursivem SELECT
- Index(es):
Relevant Pages
|