Forum: Rails France optimisation requete sql

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2006ddf092f3a693748d061a66048159?d=identicon&s=25 Olivier AUDRY (Guest)
on 2006-05-10 16:31
(Received via mailing list)
Bonjour,

j'ai dans mon code :

Astreinte.update_all "validated = 1", :conditions =>
["astreintes.user_id = ?", @session[:user].id )

chose qui me semble être une requête correcte. Cependant dans les
logs de l'application j'ai ça :

 Astreinte Load (0.000590)   SELECT * FROM astreintes WHERE
(astreintes.id = 18) LIMIT 1
 Astreinte Update (0.000664)   UPDATE astreintes SET `validated` = 1,
`date` = '2006-05-10 21:07:00', `comment` = '***', `escalade` = 'non',
`customer` = '****', `machine` = '****', `ticket_number` = *****,
`call_type` = '****', `user_id` = 10, `spend` = '10min', `source` =
'****' WHERE id = 18

et ceci pour chacune des entrées. je ne suis pas un expert en sql mais
cette requête ne me parait optimum non ?

merci pour vos lumières

Cordialement

Olivier AUDRY
2006ddf092f3a693748d061a66048159?d=identicon&s=25 Olivier AUDRY (Guest)
on 2006-05-10 16:43
(Received via mailing list)
il y a une petite erreur de syntaxe, il faut lire :

Astreinte.update_all "validated = 1", :conditions =>
["astreintes.user_id = ?", @session[:user].id

cordialement

Olivier AUDRY
30d2fbcfa70a6ed4fd0bceda145f3758?d=identicon&s=25 Benjamin Francisoud (Guest)
on 2006-05-11 10:09
(Received via mailing list)
Ce qui t'embête avec ce code c'est la select qu'il fait avant le update
si je comprend bien ?

<hypothèse>Je ne sais pas si c'est normal, mais je pense que c'est pour
limiter les risques d'accès concurrent, ça "rafraîchit" les données
avant de les updater...</hypothèse>

Une explication de l'accès concurrent:
http://www.hibernate.org/hib_docs/v3/reference/fr/...

Si tu as pas de problème de perf, à ta place, je me prendrais pas la
tête ;)
http://www.extremeprogramming.org/rules/optimize.html

--
Benjamin Francisoud
http://rubyscube.blogspot.com
400818411253800c62377dcac0b771d7?d=identicon&s=25 Yannick Francois (Guest)
on 2006-05-11 10:45
(Received via mailing list)
> >>
>

Le seul interête que je vois à ça, c'est de mettre l'enregistrement en
mémoire. Ceci peut être interessant mais ça dépends du moteur de base de
donnée utilisé. Je suis pas certain de l'interet non plus. Faire un
select
sur un enregistrement, avant de le mettre à jour... Surtout que
normalement
le update est découpé en un pseudo select (forcement pour récupérer
l'enregistrement) puis la mise à jour.
Bref, le seul truc la dedans c'est que du coup, si le query cache est
activé, le resultat du pseudo select de l'update est déjà en cache grace
au
premier select. Mais ça ne sert à rien car de toute façon le select à
déjà
eu lieu.

Tout ça pour dire que non c'est pas utile, par contre je suis pas sur
que ça
te fasse perdre beaucoup de temps, donc ce n'est pas optimisé, mais
l'optimisation de cette requête n'apporteras pas grand chose.

Si tu veux gagné du temps sur cette requête, à la limite c'est sur la
définition des champs de la table astreintes et sur les eventuelles
index
qu'il faut travaillé, pas sur la requête.

My 2 cents,

;-)
2006ddf092f3a693748d061a66048159?d=identicon&s=25 Olivier AUDRY (Guest)
on 2006-05-11 11:10
(Received via mailing list)
merci pour ces explications. Effectivement au niveau optimisation je ne
me fait pas de soucis je fait comme tout le monde je sur dimensionne ma
machine ... mes deux machines base et frontal.

voila c'était juste pour information ça me paraissait bizarre.

Cordialement

Olivier AUDRY
This topic is locked and can not be replied to.