17-05-2011, 09:01 AM
@Ter Rowan : j'osais pas en parler, je risque d'avoir des trucs dans ce genre là aussi, mais entre le stockage de la règle en base de donnée (comme ici la table des prérequis) et la validation, je pense qu'effectivement, en pur SQL ça risque d'être chaud... à moins de passer par des tables intermédiaires, des triggers pour mettre à jour ces tables quand un bâtiment est construit, etc...
@niahoo : le but n'est pas spécialement de faire le moins de requête possible, mais plutôt de faire l'opération avec un temps le plus court possible.
Pour ça, il y a des choses a éviter en SQL :
- les OR dans un WHERE par exemple font perdre une bonne partie des avantages liés aux index,
- les requêtes imbriqués sont générale exécuté pour chaque enregistrement de la requête parente (donc gros ralentissement),
- enfin les jointure gauche (LEFT JOIN) sont à utiliser judicieusement car elles ont tendance à multiplier énormément le nombre d'enregistrement à traiter par le WHERE, il faut donc les utiliser sur des index et de manière à limiter les résultats.
- dernier point, l'ordre des tables peut aussi jouer sur les perfs.
Dans mon dernier exemple par exemple, faire un UNION, c'est presque comme faire deux requêtes finalement.
Sinon, personnellement, je ne suis pas partisan de la requête construite dynamiquement, c'est en général source de failles de sécurité, peu performant, et souvent tu perds plus de temps à construire cette requête, en plus tu contrôles du coup beaucoup les performances de ta requête. C'est valable pour des petits trucs, mais là, si l'on prend l'exemple de Ter Rowan, tu peux rapidement généré une requête usine à gaz je pense. Mais bon, c'est plus un avis personnel là.
@niahoo : le but n'est pas spécialement de faire le moins de requête possible, mais plutôt de faire l'opération avec un temps le plus court possible.
Pour ça, il y a des choses a éviter en SQL :
- les OR dans un WHERE par exemple font perdre une bonne partie des avantages liés aux index,
- les requêtes imbriqués sont générale exécuté pour chaque enregistrement de la requête parente (donc gros ralentissement),
- enfin les jointure gauche (LEFT JOIN) sont à utiliser judicieusement car elles ont tendance à multiplier énormément le nombre d'enregistrement à traiter par le WHERE, il faut donc les utiliser sur des index et de manière à limiter les résultats.
- dernier point, l'ordre des tables peut aussi jouer sur les perfs.
Dans mon dernier exemple par exemple, faire un UNION, c'est presque comme faire deux requêtes finalement.
Sinon, personnellement, je ne suis pas partisan de la requête construite dynamiquement, c'est en général source de failles de sécurité, peu performant, et souvent tu perds plus de temps à construire cette requête, en plus tu contrôles du coup beaucoup les performances de ta requête. C'est valable pour des petits trucs, mais là, si l'on prend l'exemple de Ter Rowan, tu peux rapidement généré une requête usine à gaz je pense. Mais bon, c'est plus un avis personnel là.