Optimisation de requete

Bonjour,
Je possède deux tables T1 et T2, je souhaite copier certaines informations de la table T2 dans ma table T1 (utilisation d'un Update)

Code:

---

1 2 3

UPDATE T1 SET T1.val1 = SELECT T2.val1 FROM T2 WHERE T2.guide = T1.guide WHERE "ma condition sur T1"

---

Le problème, c'est que dans le cas ci-dessus, je ne mets à jour qu'une seule valeur, hors je souhaite en mettre plusieurs car je peux en récupérer plusieurs avec la même requete de sélection...

En gros je voudrais faire:

Code:

---

1 2 3

UPDATE T1 SET T1.val1,T1.val2,... = SELECT T2.val1,T2.val2,... FROM T2 WHERE T2.guide = T1.guide WHERE "ma condition sur T1"

---

Mais il me jette à la virgule après "T1.val1"

Donc d'après ce que j'ai compris, il faudrait que je fasse:

Code:

---

1 2 3 4 5

UPDATE T1 SET T1.val1 = SELECT T2.val1 FROM T2 WHERE T2.guide = T1.guide , T1.val2 = SELECT T2.val2 FROM T2 WHERE T2.guide = T1.guide , T1.*** = SELECT T2.*** FROM T2 WHERE T2.guide = T1.guide WHERE "ma condition sur T1"

---

Le problème c'est que je souhaite updater 16valeurs alors ça me gêne de devoir faire 16 requete SELECT (identiques, excepté la valeur retournée) d'autant plus que cette requête SELECT est plus compliquée que ci-dessus...

QQn aurait-il une idée ou un conseil ? :?

Est-ce que tes 16 valeurs appartiennent à chaque fois au même enregistrement (à la même ligne) ?

Dans ce cas, il devrait suffire de faire:

Code:

---

1 2 3

UPDATE T1 SET T1.val1 = T2.val1, T1.val2 = T2.val2, T1.val3 = T2.val3, ... WHERE ...

---

sinon, je pense que t'as pas le choix et il faudra que tu fasses une requête pour chaque valeur

Merci pour l'aide...

En fait j'ai réussi en utilisant des curseurs...

Citation:

---

Envoyé par Scorff

Merci pour l'aide...

En fait j'ai réussi en utilisant des curseurs...

---

Mauvaise idée :evil:

Peut etre mauvaise idée, mais qu'on on est débutant qu'on trouve quelquechose qui marche et qui simplifie la requete... on l'utilise...

Au lieu de critiquer, propose alors ! Explique pourquoi c'est une mauvaise idée, la critique est facile... :D

L'update vous a déjà été fourni par drinkmilk. Le T-SQL permet l'utilisation de la clause FROM dans un UPDATE, ce qui est fort pratique, mais pas possible sous d'autre SGBDR tels que DB2 ou Oracle, où il faut passer par des sous-select (comme ceux appraissant dans votre premier post)

Le curseur est une mauvaise idée pour des raisons de performances énumérées de nombreuses fois sous ce même forum. Il bufferise souvent plus de données qu'il n'en faut, est lent à "fetcher", pose trop de verrous lents... et surtout est utilisé à mauvais essient : traitement séquenciel dans un language ensembliste.

Voilà pour ce qui est de la critique facile :twisted:

Citation:

---

Envoyé par fadace

Le curseur est une mauvaise idée pour des raisons de performances énumérées de nombreuses fois sous ce même forum.

---

Quels sont ces performances ?
Pour info, la requete que je fais passe toutes les nuits, je n'ai donc aucune contrainte horaire.
De plus actuellement, et ce malgrès la taille conséquente des tables que je manipule le traitement ne dure pas plus de 1min... :D et cela me convient très bien!
Pourquoi m'embeter alors à modifier une nouvelle fois ma requête ?

Surtout que je ne vois pas comment faire d'autre...

Pour vote premire question, un fetch d'une table est approximativement (ça dépend des versions) 5 fois plus lent qu'un table scan.

A vous de voir votre façon de programmer ! J'attire juste votre attention que de mauvais plis pris sur de petits traitements sont la cause majeure de près de 80% des demande de tuning sur gros volumes par la suite.

Et bien merci pour le conseille...
Je pense que j'irais faire une petite modif de ma requete dès que j'en aurais le temps.

En tout cas, merci pour les infos. :ccool: