Peformance en requete sql multitable

voici la situation
Je dispose d’une table compagnie et une table adresse.
Les date de dernière modification de la compagniesont stockées. Si une adresse de la compagnie, la date de modification sera sera modifié dans l’enregistrement correspondant dans la table adresse … mais pas dans la table compagnie (on me suit jusque là?).
Je dois donc sortir la liste des compagnie modifier (compagnie elle meme ou adresse) depuis une certains date.
Je fait donc un truc du genre:

Je voudrais savoir si c’est le style de requete le plus optimisé car je dois faire celle là sur 6 millions de compagnie et la date de modification sur 4 autres table (adresse, alias …) et en faisant tourner ca sur une base de test ca a l’air pas super rapide.

En theorie, pour ameliorer les choses, il faudrait:

_Faire une vue.
_Faire des index (sur les champs qu’on mets dans WHERE, je crois).

C’est du MySQL? Vous etes le maillon faible, Au revoir :stuck_out_tongue:

LoneWolf
Phear le maillon faible :stuck_out_tongue:

Mets déjà des index la ou tu fais tes jointures. Ca devrait accélerer pas mal je pense. sinon utilise des JOIN au lieu de faire des jointures implicites j’ai entendu dire deca et la que c’était plus rapide.

et puis moi de prime abord j’aurais fait:

SELECT CleCompagnie FROM compagnie,adress WHERE ModifComp>20050101 AND ModifAd>20050101 AND AdCompagnie=CleCompagnie

Enfin moi je la trouve bizarre ta requête, a faire une jointure dans un OR… mais je suis pas un spécialiste SQL…

Euh lonewolf1, MySQL est une des BDD les plus rapides, justement parce qu’elle gère pas plein de trucs qui peuvent être utiles (dixit mon admin réseau).

[quote name=‹ LoneWolf › date=’ 26 Jan 2005, 15:18’]En theorie, pour ameliorer les choses, il faudrait:

_Faire une vue.
_Faire des index (sur les champs qu’on mets dans WHERE, je crois).

C’est du MySQL? Vous etes le maillon faible, Au revoir  :stuck_out_tongue:

LoneWolf
Phear le maillon faible  :stuck_out_tongue:
[right][post=« 325945 »]<{POST_SNAPBACK}>[/post][/right][/quote]
+1 pour cette solution, je vois pas mieux a faire.

[quote name=’[PERE]Cil’ date=’ 26 Jan 2005, 15:22’]Euh lonewolf1, MySQL est une des BDD les plus rapides, justement parce qu’elle gère pas plein de trucs qui peuvent être utiles (dixit mon admin réseau).
[right][post=« 325947 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Bah vas y, fait des vues avec mysql, je te regarde faire en rigolant la :stuck_out_tongue:

Et passe en innodb avec mysql, et pleure la vitesse qui n’est plus la par rapport a une BDD en MyISAM.

LoneWolf
MySQL, c’est l’access de linux :stuck_out_tongue:

Boah oui mais nan faut être fou pour claquer 6 millions d’enregistrement en innoDB si t’as besoin de vitesse.

Bah au vu de vos réponses je crois finalement que je vais modifier la base pour créer ces index.
J’aurais préféré sans mais bon …

[quote]SELECT CleCompagnie FROM compagnie,adress WHERE ModifComp>20050101 AND ModifAd>20050101 AND AdCompagnie=CleCompagnie
Enfin moi je la trouve bizarre ta requête, a faire une jointure dans un OR… mais je suis pas un spécialiste SQL…[/quote]
Non parce que une compagnie peut avoir été modifié sans que son adresse le soit.

Sinon c’est sur SQLserver

Beurk un OR c’est forcement lent du coup… 6 millions c’est pas beaucoup, mais bon ce genre d’optimisation c’est un metier un peu et c’est difficile a faire sans qu’on puisse avoir acces a tout le bordel (genre voir tous les index presents, les requetes que tu fais exactement, etc). Tu as des outils genre sql profiler qui sont fourni avec qui te permettent de savoir exactement ou tu perds du temps et un outil pour te dire ou mettre les index qu’il faut automatiquement, c’est deja un premier pas dans l’optimisation (qui peut aller beaucoup plus loin).