Discussion :

[MacFly58]

Bonjour,

Une discussion entre CinePhil et FsmRel m'interpelle :

FmsRel:

Citation:
Envoyé par CinePhil Voir le message

Je n'aime pas le NATURAL JOIN, justement parce qu'il ne précise pas sur quelles colonnes porte la condition de jointure ; je ne l'emploie jamais.

Vous affaiblissez le degré d’abstraction et vous prenez le contrepied de Codd (RIP) et Date sans lesquels on en serait resté aux bases de données hiérarchiques, navigationnelles et autres listes inverses, s’ils n’avaient justement élevé le degré d’abstraction. En proposant l’opérateur NATURAL JOIN, la norme SQL a repris strictement les écrits de Date, à ceci près que dans le contexte de la théorie relationnelle, pour effectuer la jointure naturelle de A et B on écrit simplement A JOIN B. Ainsi, la jointure est effectuée sur les attributs ayant même nom (et même type, cela va sans dire). Si deux attributs n’ont pas même nom, pour la jointure on en renomme un au sein de la requête à l’aide de l’opérateur RENAME (comme en SQL on renomme au moyen de AS). Autrement dit, la recommandation implicite de Date est la suivante : si le même attribut (par exemple l’identifiant de la personne) figure dans des tables différentes, donnons-lui le même nom.

Imaginons une jointure naturelle entre 2 tables. Dans ces 2 tables, 3 colonnes portent le même nom.

Si j'écris une requête NATURAL JOIN, comment le moteur relationnel va retrouver ses petits ? Comment choisi-t-il une colonne plutôt qu'une autre ?

Sachant bien sur que je m'amuse souvent à modifier les types et que j'ai une fâcheuse tendance à rajouter ou supprimer des colonnes quand le cœur m'en dit.

Actuellement j'utilise NATURAL JOIN aussi souvent que CinePhil car cela me semble sage. Mais la sagesse n'est pas incompatible avec l'ignorance, et j'aimerai creuser un peu ce sujet.

Merci.

[Oishiiii]

Imaginons une jointure naturelle entre 2 tables. Dans ces 2 tables, 3 colonnes portent le même nom.

Si j'écris une requête NATURAL JOIN, comment le moteur relationnel va retrouver ses petits ? Comment choisi-t-il une colonne plutôt qu'une autre ?

Le SGBD ne choisira pas ! Il effectuera la jointure avec ces trois colonne comme prédicat de jointure exactement comme en SQL.

Code SQL :

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

1
2
3
4
5
6
 
FROM tableA AS a
    JOIN tableB AS b
        ON a.colA = b.colA
        AND a.colB = b.colB
        AND a.colC = b.colC

Pour exclure certaines colonnes, en souhaitant malgré tout utiliser une jointure naturelle, il faut renommer ces colonnes au préalable dans la requête.

Exemple en Tutorial D pour exclure colA:

Code Tutorial D :

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

1
2
( tableA RENAME (colA AS colAbis) ) JOIN tableB

[SQLpro]

1) NATURAL JOIN est une fonction avancée de la norme SQL que peu de SGBDR ont mise en place à cause des danger que cela représente en production
2) la norme AFNOR sur les SI préconise que dans tout SI chaque information possède un nom strictement différent au sein du SI. Ainsi un nom de produit n'est pas un nom de personne et il faudrait mettre NOM_PRODUIT et NOM_PERSONNE
3) le NATURAL JOIN est accompagné d'une clause complémentaire facultative USING qui précise quelles colonnes doivent être utilisée pour cette jointure. En son absence toutes les colonnes de même nom sont utilisées.
4) si des colonnes de même nom n'ont pas un type "compatible", alors cela doit générer une erreur
5) le danger le plus important vient du fait qu'au cours de la vie de la base de données, on est amené à rajouter des colonnes (évolution normale de toute application). Si l'on rajoute une colonne de même nom dans deux tables différentes et pour des concepts différent, alors il y a toutes les chances pour que l'application ne fonctionne plus !

C'est pourquoi il est fortement déconseillé d'utiliser le NATURAL JOIN qui est un piège.

A +

[fsmrel]

Comme le fait observer SQLpro, se baser sur le seul nom des colonnes est évidemment risqué, c'est-à-dire quand on utilise seulement les types de base (integer, char, date, etc.) qui sont trop génériques, tandis que dans le contexte relationnel on crée systématiquement ses propres types (façon strong typing) avec les opérateurs qui vont bien et tout ça. En revanche, dans le contexte SQL, créer ses propres types n’est pas chose aisée, et les SGBD SQL ne nous facilitent pas la vie à ce sujet. Dans de telles conditions, on se cantonne donc aux types de base et les homonymies deviennent risquées, ce qui fait qu’éviter NATURAL JOIN est justifié.
Pour ma part, j’ai pu donner l’impression de me faire l’avocat de cette version de JOIN, et je l’ai peut être utilisée deux ou trois fois histoire de voir, mais il est évident que dans un contexte de production on redevient sérieux. De toutes façons, comme je l’ai fait remarquer notamment ici, les administrateurs de données en relation avec la production définissent les normes pour les noms des différents objets, en particulier tables et colonnes qui en général portent des noms hermétiques.

Et puis en cas de doutes sur les collisions, au moyen du catalogue relationnel (merci Ted Codd), on peut toujours effectuer les contrôles qui peuvent s’imposer.

Il n’en demeure pas moins qu’au niveau théorique, l’étude de cet opérateur, comme beaucoup d’autres est intéressant, et comme je l’ai dit, on peut, chercher à élever le niveau d’abstraction (n'est-ce pas, Oishiiii ? ), c’est comme cela qu’on procède en relationnel et qu’on avance, en observant par ailleurs comment les choses se passent sur le terrain. A défaut, on continuerait à faire du DL/1 ou de l'IDS/2, avec à la clé une semaine pour construire une requête qui nécessite au plus une paire d'heures en SQL, tests compris (mais pas la pause café)...

[CinePhil]

On est donc bien d'accord que NATURAL JOIN est inutile car dangereux en pratique !
=> Poubelle !