Discussion :

[Aurélien LEQUOY]

Voilà, je cherche des "preuves" ? Il paraitrait que la requête suivante de ce type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT * 
FROM   employee, department 
WHERE  employee.DepartmentID = department.DepartmentID;

serait davantage "performant" que celle ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT *
  FROM employee INNER JOIN department
    ON employee.DepartmentID = department.DepartmentID;

Pour moi c'est qu'une question d'écriture et strictement identique au niveau du plan d'exécution, mais certains collègues pensent le contraire (prêt en débattre avec les mains lol). Donc si qqn d'entre vous avez déjà eu un cas ou la première requête serait plus performante que la 2eme n'hésiter pas à nous donner un exemple.

[mpeppler]

Il n'y a strictement aucune difference de performance. Les deux formes sont équivalentes.
Tu peux le vérifier en regardant le plan des deux forme (set showplan on)

Pour moi, la forme ANSI (avec JOIN ... ON ...) est à préférer parce que plus expressive, et plus correcte lorsque l'on utilise des OUTER join.

Michael

[mpeppler]

Beaucoups de collègues sont réticents à utiliser la forme ANSI par un manque d'habitude. J'ai aussi eu de la peine au début, mais après quelque temps je ne fais plus que cela, aussi parce qu'une jointure complexe (10+ tables) devient illisible dans l'ancien format, alors qu'en mode ANSI on peut bien suivre quelle table joint avec quelle autre.

Michael (qui code en T-SQL depuis 1989...)

[Aurélien LEQUOY]

Cela confirme bien ce que je pensais ! merci

[Arnaud F.]

Beaucoups de collègues sont réticents à utiliser la forme ANSI par un manque d'habitude. J'ai aussi eu de la peine au début, mais après quelque temps je ne fais plus que cela, aussi parce qu'une jointure complexe (10+ tables) devient illisible dans l'ancien format, alors qu'en mode ANSI on peut bien suivre quelle table joint avec quelle autre.

Michael (qui code en T-SQL depuis 1989...)

Personnellement, je suis dans le même cas de figure, des collègues réticents a cette norme et utilise toujours l'ancienne méthode de jointure.

Je me mets petit à petit à la norme mais c'est vrai que c'est pas évident au premier abord

Sinon +1 pour tout ce qu'a dit Michael, les requêtes sont strictement identiques.

Arnaud (qui code en T-SQL depuis 2008 )

[mpeppler]

Je conseil très fortement d'adopter la forme ANSI.

P.ex. query pour extraire les colonnes/types pour une table, en mode "ancien":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
SELECT DISTINCT
       Column_name  = c.name,
       Type         = t.name,
       Length       = c.length,
       Prec         = c.prec,
       Scale        = c.scale,
       Nulls        = convert(bit, (c.status & 8)),
       Default_name = object_name(c.cdefault),
       Rule_name    = object_name(c.domain),
       Ident        = convert(bit, (c.status & 0x80)),
       Default_Ddl  = isnull (d.status & 4096, 0),
       Rule_Ddl     = isnull (r.status & 4096, 0),
       DefaultId    = c.cdefault,
       RuleId       = c.domain,
       Column_len   = char_length(c.name),
       Type_len     = char_length(t.name)
  FROM dbo.syscolumns    c
      ,dbo.systypes      t
      ,dbo.sysprocedures d
      ,dbo.sysprocedures r
 WHERE c.id        = object_id('sysobjects')
   AND c.usertype *= t.usertype
   AND c.cdefault *= d.id
   AND c.domain   *= r.id
 ORDER BY c.colid

Si je recode en mode ANSI:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
select ...
from
    syscolumns c
    left join systypes t
        on t.usertype = c.usertype
    left join sysprocedures d
        on d.id = c.cdefault
    left join sysprocedures r
        on r.id = c.domain
where
    c.id = object_id('sysobjects')

J'écris toujours la query dans l'ordre naturel (prends une ligne dans syscolumns, va trouver la ligne correspondantes dans systypes, dans sysprocedures, etc.) et je mets toujours la table référencée à gauche dans la clause ON. Cela permet de rapidement comprendre comment la query est construite.

Les jointures ANSI permettent aussi de faire des jointures imbriquées, et en mode developpement/debugging c'est trivial de commenter un partie de la jointure pour comprendre des jointures qui ne ramènent pas ce qui est escompté:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
select *
from
    syscolumns c
    left join systypes t
        on t.usertype = c.usertype
    left join sysprocedures d
        on d.id = c.cdefault
--    left join sysprocedures r
--        on r.id = c.domain
where
    c.id = object_id('sysobjects')

(bon, cet exemple n'est pas très parlant, mais si on considère une query avec 10 ou 15 tables (et j'en ai plein) le fait de pouvoir executer une partie de la query facilement permet un gain de temps appréciable...

Michael

[Fabien Celaia]

Je plusoie avec un bémol.

En inner join, sous Sybase ASE, les formes sont identiques.

Il n'est est rien en ce qui concerne, si je ne m'abuse, l'OUTER JOIN lorsque l'on conditionne sur la table externe. Je crois me souvenir que le comportement de l'ASE en version *= n'est pas similaire à la norme, mais que le comportement est correct via l'OUTER JOIN.

Une raison de plus pour utiliser la jointure ANSI qui a le mérite de dissocier clairement conditions de jointures et conditions fonctionnelles.