Discussion :

[Wisefool]

Bonjour,
je viens de tomber sur la requete suivante:

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
CREATE OR REPLACE VIEW language_v AS
SELECT	a.person_id,
	a.first_name,
	a.last_name,
	b.language_name,
	c.fluency_id language_level,
	d.fluency_name level_description
FROM psn_person a,
	pik_language b,
	psn_language_fluency c,
	pik_language_fluency d,
	psn_off_career_job_type_dept e
where a.person_id = c.person_id (+)
AND c.language_id = b.language_id (+)
AND c.fluency_id = d.fluency_id (+)
AND	a.person_id		= e.person_id ;

à quoi correspondent les '+' qui sont entre parenthèses?

[Médiat]

Se sont des jointures externes, syntaxe non normée et spécifique ORACLE; à partir de la version 9i, il est vivement conseillé d'utiliser la syntaxe normée (LEFT ou RIGHT OUTER JOIN, voire, FULL OUTER JOIN)

[Yorglaa]

... à partir de la version 9i, il est vivement conseillé d'utiliser la syntaxe normée (LEFT ou RIGHT OUTER JOIN, voire, FULL OUTER JOIN)

Pourquoi ?

[Wisefool]

ah ok merci
je me doutais bien que c'était des jointures mais bon, n'ayant jamais vu cette syntaxe je preferais etre sur

[Médiat]

Portabilité, lisibilité des requêtes, possibilité d'écrire des choses impossibles avec la syntaxe avec le (+) (ne serait-ce que les FULL OUTER JOIN). A terme (mes tests personnels ne m'ont pas permis de démontrer une différence fondamentale dans la 9i), l'optimisation risque d'être meilleure, voire, l'ancienne syntaxe risque de ne plus être supportée...

J'ai mis en gras lisibilité, car ce seul aspect, pour moi, est suffisant pour justifier cet usage.

[orafrance]

le problème c'est quand on fait de jointure de jointure de jointure... c'est vite le casse-tête avec la norme

Wisefool pour t'améliorer : http://oracle.developpez.com/guide/developpement/sql/

[plaineR]

le problème c'est quand on fait de jointure de jointure de jointure... c'est vite le casse-tête avec la norme

Je suis tout à fait d'accord avec toi, et là je ne suis pas sûr que l'on gagne en lisibilité.

[Yorglaa]

Ca ! Je doit avouer que je ne vois AUCUN bénéfice en terme de lisibilté...
Mais je suppose que la force de l'habitude...

[Médiat]

Code :

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

1
2
3
4
5
6
7
8
SELECT   a.person_id, a.first_name, a.last_name, b.language_name, 
         c.fluency_id language_level, d.fluency_name level_description 
FROM psn_person a 
      INNER JOIN psn_off_career_job_type_dept e ON a.person_id   = e.person_id 
      LEFT OUTER JOIN psn_language_fluency c    ON a.person_id   = c.person_id
      LEFT OUTER JOIN pik_language b            ON c.language_id = b.language_id
      LEFT OUTER JOIN pik_language_fluency d    ON c.fluency_id  = d.fluency_id
WHERE ...

Je trouve cela beaucoup plus lisible que la première requête, ne serait-ce que parce qu'il y a une différence marquée entre les conditions de jointures et les conditions de recherche (et encore j'aurais pu utiliser USING à la place du ON).

[orafrance]

je suis d'accord, ça permet de distinguer très nettement les jointures des clauses restrictives... n'empêche que pour les requêtes complexes ça devient illisible

[Yorglaa]

ben moi je trouve pas, désolé... mais des goûts et des couleurs !

de plus, dès que tu commence à avoir dans ta clause FROM de "choses" qui ne sont plus aussi simplement formattées qu'un simple nom de table, comme :
- des Inline-Views
- des "fonction - tables" (pipelined functions)
- le tout mixé avec une clause WITH en début de script pour la réutilisabilité de certains sous-select...

là tu commence VRAIMENT à te perdre facilement... parceque comme ça, la clause FROM n'est plus aussi "simple".

[orafrance]

c'est ce que je voulais dire par "requêtes compliquées"

[Yorglaa]

je suis d'accord, ça permet de distinguer très nettement les jointures des clauses restrictives... n'empêche que pour les requêtes complexes ça devient illisible

pour ça, rien n'empêche de "séparer" les jointures des clauses de restrictions :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Select
        ...
From    
        T1
        , T2
        ...
Where
        /* jointures */
            T1.Id = T2.Id
        And    ...
        /* rectrictions */
        And    ...

edit : orafrance, désolé, nos message se croisent...

[orafrance]

En effet mais je ne rejette pas la norme en bloc, de plus pour les jointures externes elle est à mon avis plus clair que le (+) (que je ne sais jamais de quel coté mettre ). Ca ne m'empêche pas de penser que certaines possibilités offertes par Oracle rendre la norme plus compliquée à mettre en oeuvre comme tu le soulignes

[Wisefool]

Wisefool pour t'améliorer : http://oracle.developpez.com/guide/developpement/sql/ Smile

merci orafrance


sinon je constate avec délectation que ma question toute simple a généré un petit débat plutot animé
content de contribuer à la vie de ce forum
à titre entierement personnel, je dois dire que je suis pour la norme
pasque dans mon cas je devais réécrire la requete (légèrement modifiée pour mes besoins) sous sql server et que quand on connait pas la syntaxe propre à oracle, c'est quand meme plus lisible d'avoir join en toute lettre

[plaineR]

Moi aussi je suis pour la norme, mais cela ne m'empêche pas de la trouver moins lisible.

[orafrance]

c'est évident, il vaut mieux développer de manière normée et ce quelque soit le langage

[Médiat]

là tu commence VRAIMENT à te perdre facilement... parceque comme ça, la clause FROM n'est plus aussi "simple".

Des goûts...
Mais je ne vois pas en quoi l'écriture non normée apporte quoique ce soit en lisibilité, même (surtout) dans les cas que tu décris.

[orafrance]

pas de lisibilité mais un gain de temps lors du développement parce que c'est beaucoup plus facile à écrire... du moins c'est mon avis

[Yorglaa]

et bien simplement parce que lorsque la clause FROM est faite de vues en lignes (par exemple), elle est donc elle-même faite de Select qui eux-meêmes possèdent leurs propres jointures...

Donc, partant, il est plus lisible d'établir (et de tester) ses Select de vue en ligne, de les intégrer dans la clause from PUIS d'établir les jointures entre ces différentes vue dans la clause WHERE.

par exemple, comment rendre "lisible" ceci en code normalisé ?

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
26
27
28
29
30
31
32
Select
        ...
From
        T1
        ,(
            Select
                    T2.X
                    , nvl(T4.Y, 0)
            From
                    T2
                    , T3
                    , (
                       Select Distinct
                                T4.id2
                                , T4.Y
                       From
                                T4
                      ) T4
            Where
                    T2.id = T3.id
            And     T2.id2 = T4.id2 (+)
                    T2.DateFrom = (
                                    Select
                                            max(TX.DateFrom
                                    From    T2 T2Bis
                                    Where   T2Bis.id = T2.id
                                  )
            And     T4.N > 5
        )   Z
Where
        T1.X = T2.X
And     Z.X = 2

PS là j'ai vraiment fais n'importe quoi, sans vérifier