Discussion :

[frais_d_eric]

bonjour à tous,

je n'ai pas un niveau ultime en sql et je souhaite remplacer des curseurs de mise à jour de données pas des UPDATE ... FROM.
Tous se passe bien à priori sauf qu'un collègue me soutient qu'il vaut mieux éviter cela même si les curseurs sont immensément moins performant (j'avoue ne pas avoir compris les explications qu'il m'a fourni alors ).
Bref, il me déconseille l'utilisation de cette construction UPDATE en précisant qu'un UPDATE ne s'utilise qu'avec une seule table même si la clause FROM existe.

Est-ce pertinent ? (et si oui pourquoi si vous avez la patience d'écrire )

Merci beaucoup

a++

[elsuket]

Bonjour,

Effectivement l'instruction UPDATE ne permet de mettre à jour qu'une seule et unique table, comme d'ailleurs les autres instructions de mise à jour (INSERT et DELETE).
Cependant vous pouvez effectuer l'UPDATE avec une jointure, mais vous devez dans ce cas là répéter le nom de la table :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
UPDATE dbo.maTable
SET maColonne0 = A.uneColonneDeA,
	maColonne1 = B.uneColonneDeB
FROM dbo.maTable T
[INNER |LEFT | RIGHT | FULL] JOIN dbo.uneTableA AS A ON A.ID_A = T.ID
[INNER |LEFT | RIGHT | FULL] JOIN dbo.uneTableB AS B ON B.ID_B = A.uneAutreColonneDeA

Dans tous les cas l'exécution d'une requête UPDATE est forcément plus rapide et moins coûteuse en ressources qu'un vieux curseur qui date de COBOL (1956 ...)

Les SGBDR sont conçus pour manipuler des ensembles de données relationnelles, par pour faire du ligne-à-ligne

@++

[frais_d_eric]

Merci beaucoup pour votre réponse.

Donc si j'ai bien compris, rien ne s'oppose à l'utilisation d'UPDATE avec jointure pour remplacer certains curseurs simples de mise à jour de données provenant d'autre(s) table(s).

Merci encore.

[SQLpro]

un collègue me soutient qu'il vaut mieux éviter cela [UPDATE... FROM] même si les curseurs sont immensément moins performant [...]
Bref, il me déconseille l'utilisation de cette construction UPDATE en précisant qu'un UPDATE ne s'utilise qu'avec une seule table même si la clause FROM existe.

Cette position est parfaitement idiote et relève l'inculture crasse de certains techniciens.
Il y aurait mille argument masse à dire sur le sujet pour contrer cette ineptie. Je n'en donnerais qu'une.
En étant plus lent, le curseur verrouille donc plus longtemps les ressources, ce qui provoque de la contention, qui se traduit par des temps d'attente, voir des time out et au pire des dead locks...
Bref, une excellente idée pour pourrir les performances d'un SGDBR.
Visiblement votre collègue est un survivant du temps des dynosaures !

A +

[frais_d_eric]

Visiblement votre collègue est un survivant du temps des dynosaures !
A +

Je n'osais pas le dire, mais c'est également constaté sur d'autres sujets pour cette personne...

Malheureusement, certains chefs de services confondent expérience professionnelle pertinente et bagou...

merci SQLpro