Rebonjour,
je vien de me faire tuer par mon chef suite aux messages que je vous ai posté précédemment.

Je fait mes jointures avec INNER JOIN, tandis que mon chef fait des sous requetes pour ses "jointures".Il me dit qu'il a raison parcque les tables nont pas de relation!Hors avec Mysql je fait bien des inner join alors que cette base ne permet pas de gérer les relations.
Le plus fort c'est qu'il me dit que le serveur lors de l'utilisation d'un JOIN sans relation entre deux table crée une table d'index en mémoire qu'il relache ensuite après l'éxécution de la requete!

J'ai toujours appris que les "JOIN" étaient bcp plus rapide que les sous requetes peut importe le model et la volumétrie de la base!
j'ai jamais vu ca!

Qu'en pensez-vous?

Qu'en pensez-vous?

Difficile de dire sans connaître le serveur de base de données en question, mais en général le chef a toujours raison donc... À priori je ne vois pas de différence entre une jointure et une sous-requête, et un bon optimiseur* devrait être en mesure de remplacer le second par le premier à chaque fois que c'est nécessaire. Essaie les deux, vois ce qui est le plus rapide et si une jointure est plus rapide demande à ton chef de t'expliquer pourquoi. Un bon chef apprécie que ses subordonnés s'impliquent dans leur travail


* l'"optimiseur" dont je parle est une partie du programme de la base de données qui s'occupe de réécrire partiellement les requêtes qu'il reçoit pour les rendre optimales, c'est un processus transparent (invisible pour l'utilisateur)

Le blemme est pas la rapidité de la requete, il me dit que ce peut etre plus rapide mais que le cpu monte en charge, on bosse sur des sites de rencontre ou la charge est énorme.Il travaille sans relation du fait d ela volumétrie il ne veux pas se surcharger en maintien de relation c trop couteux comme il dit.Bref je me suis pris un savon quoi!
Il dit que lors d'un INNER JOIN une table d'index est crée en mémoire afin de comparer les champs. et que c'est super couteux

Il dit que lors d'un INNER JOIN une table d'index est crée en mémoire afin de comparer les champs. et que c'est super couteux

Selon le SGBDR, c'est tout a fait possible que les INNER JOIN et sub-requests ne soient pas equivalents.
Difficile de te repondre sans en savoir plus.

SQL SERVER!

Quelq'un maitrise cette base?
Notre modele est le suivant: forte volumétrie et pas de relation!

SQL SERVER!
Quelq'un maitrise cette base?

J'ai bossé dessus et ca m'etonne beaucoup ce que ton chef decrit ici. D'apres la doc, il vaut mieux utiliser des INNER JOIN plutot que des subrequests, le nombre de lignes concernees etant ainsi moins important.

Cela dit :

il me dit que ce peut etre plus rapide mais que le cpu monte en charge

... ne veut pas dire grand chose. Ca ressemble beaucoup a de la mauvaise fois.
Conclusion => ecrase-toi, c'est ton chef, et il ne reconnaitra jamais que tu as raison sur ce point.

ouais,
Mais il me dit que comme il n'ya pas de relation le fait d'apeller une jointure crée une table d'index en mémoire pour calculer les associations.
Dans ce cas le "select in" de la sous requete ferai la même chose!
Ne confondrai t-il pas jointures et relation?

1/ On peut faire des jointures entre les colonnes de deux tables distinctes même s'il n'y a pas de "relation" (foreign key)
2/ SQL Server peut créer un index temporaire (REFORMATING TABLE) pour réaliser une jointure s'il n'y pas d'indexe. S'il y a un index déja existant ... il l'utilise
3/ Entre une sous requête ou INNER JOIN pour une jointure les performances seront identiques.
4/ Une requête sans index sur la colonne FK sera plus longue que la même requête avec index (aussi bien avec INNER que sous select)
5/ Si le reste du monde utilise des INNER JOIN plutot que des sous select. C'est surement ton chef à raison et le reste du monde à tort ....
6/ Pour plus d'info sur le plan d'execution de ta requête passe cette commande avant ta requête (niveau session ne touche pas le reste du serveur)

Interessant je vais regarder ça de plus prêt