Discussion :

[Loudgi]

Bonjour à tous,

J'ai une requête qui me permet de récupérer les tiers d'une application. Le soucis est que ça me retourne parfois, plusieurs fois le même tiers si il a plusieurs adresse.

Je veux donc modifier la requête pour que ça récupère aléatoirement une adresse (dans un 1er temps) pour 1 tiers. Ainsi je n'aurai plus plusieurs fois le même tiers pour chaque adresse.

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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
select 
'Numero' ||';'||
'DateCreation' ||';'||
'Civilite' ||';'||
'Nom' ||';'||
'Prenom' ||';'||
'Telephone' ||';'||
'Fax' ||';'||
'AdresseEmail' ||';'||
'Num'||'&'||'NomVoie' ||';'||
'ComplementGeographique' ||';'||
'BoitePostale' ||';'||
'CodePostal' ||';'||
'Localite' ||';'||
'Pays' ||';'||
'DateModification' from dual;
select a.TIERS_CODE ||';'||
to_char(a.TIERS_DATCRE,'DD/MM/RRRR')||';'||
a.PP_QUALITE ||';'||
a.TIERS_NOM ||';'||
a.PP_PRENOM ||';'||
b.ADRESS_TEL ||';'||
b.ADRESS_FAX ||';'||
b.ADRESS_EMAIL ||';'||
b.ADRESS_VOIE ||';'||
b.ADRESS_COMPLT ||';'||
b.ADRESS_BP ||';'||
b.ADRESS_CPOST ||';'||
b.ADRESS_VILLE ||';'||
b.ADRESS_PAYS ||';'||
to_char(a.TIERS_DATMAJ,'DD/MM/RRRR')
from APP_ADM.PUBLIC_EXPTIERS a, APP_ADM.PUBLIC_EXPADR b
where a.tiers_code=b.TIERS_CODE
and a.tiers_type =1
group by a.TIERS_CODE, 
to_char(a.TIERS_DATCRE,'DD/MM/RRRR'),
a.PP_QUALITE ,
a.TIERS_NOM ,
a.PP_PRENOM,
b.ADRESS_TEL,
b.ADRESS_FAX,
b.ADRESS_EMAIL,
b.ADRESS_VOIE,
b.ADRESS_COMPLT,
b.ADRESS_BP,
b.ADRESS_CPOST,
b.ADRESS_VILLE,
b.ADRESS_PAYS,
to_char(a.TIERS_DATMAJ,'DD/MM/RRRR')
order by a.TIERS_CODE ;

Comment faudrait-il que je modifie la requête pour récupérer par exemple la première adresse trouvé ?

[mnitu]

Cherchez sur ce forum First/Last dans leur version agrégée.

[escartefigue]

Il suffit d'ajouter fetch first n rows only
n = 1 pour une seule ligne

Par ailleurs
- des alias un peu plus parlants que a, b ... sont recommandés, ca aide à la lecture
par exemple

Code :

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

1
2
from APP_ADM.PUBLIC_EXPTIERS TIERS, 
     APP_ADM.PUBLIC_EXPADR   ADR

avec 2 tables ca passe à peu près, mais au delà c'est vite illisible

- il est également fortement recommandé de distinguer les critères de jointures des critères de filtrage
jointure dans un prédicat inner/(full) outer join... on
filtrage dans le where

[mnitu]

...
- il est également fortement recommandé de distinguer...

Par qui ?

[escartefigue]

Par ceux qui respectent les normes SQL, qui sont soucieux de la lisibilité du code et de la portabilité

[mnitu]

En pratique la portabilité du code SQL reste un mythe et la lisibilité peut être assuré sans la norme ANSI.

[escartefigue]

même si la portabilité n'est pas à 100%, autant ne pas en rajouter et faire aussi propre que possible

Concernant la séparation des critères de jointure de ceux de filtrage, non seulement c'est la norme, mais c'est plus clair et ça ne présente aucun inconvénient.
Je ne vois donc aucune raison pour ne pas l'appliquer

Il faut toujours penser à la maintenance, plus c'est clair, plus elle est facilitée

[mnitu]

Avec quelques exceptions non significatives Oracle transforme votre requête ANSI à son sauce et cela a parfois des « effets des bords non souhaitées ».

Les constats :

• Il n’y a rien dans une requête ANSI qui vous empêche de mal écrire votre requête.
• Il n’y rien dans une requête non ANSI qui vous empêche d’écrire la requête d’une manière qui réponde parfaitement à vos exigences.

Après vous n’avez qu’utiliser ce que vous voulez. Mais ne prenez pas vos options pour des impératives.

[escartefigue]

impératives ? il faut relire plus haut

Pour le reste, si vous préférez écrire les requêtes en vrac, tant qu'il s'agit de vos développements privés, ca vous regarde, mais s'il s'agit de développements professionnels, c'est très différent.
Ne pas comprendre que des prédicats de jointures et des prédicats de filtrage sont 2 choses différentes et qu'il convient donc de les séparer, me laisse sans voix

[mnitu]

impératives ? ...
mais s'il s'agit de développements professionnels, c'est très différent.
...

Cherchez sur Internet ce que les professionnels d'Oracle pensent sur ce sujet et revenez nous faire un retour.

Ne pas comprendre que des prédicats de jointures et des prédicats de filtrage sont 2 choses différentes et qu'il convient donc de les séparer, me laisse sans voix

Oui c'est bien ça, ils ont été inventés par la norme ANSI

[escartefigue]

Inventés ? il faut encore relire mes précédents posts, décidément, la lecture n'est pas votre fort ou la sincérité, ou les 2...

Ce que disent les professionnels, en voici un florilège non exhaustif, je vous laisse chercher d'autres articles si cela vous amuse

http://psoug.org/snippet/INNER-JOIN-...syntax_730.htm
http://docs.oracle.com/javadb/10.8.3...sqlj35034.html
http://www.techonthenet.com/oracle/joins.php
http://www.orafaq.com/wiki/Inner_join
http://www.aide-oracle.net/2009/04/l...plusieurs.html

[Waldar]

C'est plus sioux que ça escartefigue.
Les jointures existent sur Oracle DB bien avant la norme SQL.
Oracle ne va pas mettre son moteur à la poubelle parce qu'une norme est sortie on est d'accord.

Pour être compatible, l'éditeur a introduit la sémantique des jointures ANSI, mais lors de l'exécution elles sont réécrites en jointure non ANSI, à coup de "," et de (+), ce qu'on constate facilement en regardant n'importe quel plan d'exécution.

Seulement, quelques bugs sont venus s’immiscer avec la fonctionnalité.
Du coup de nombreux professionnels Oracle préfèrent ne pas utiliser les jointures ANSI.

[escartefigue]

Et ben c'est pas beau ca

[mnitu]

ANSI – argh
ANSI expansion
ANSI SQL Bug