Problème de "produit cartésien"

[H.ile]

Aloha
Bon il ne s'agit pas exactement d'un produit cartésien.
Je construis une requête qui me permettra de lister un ensemble d'objet géométrique recouvrant à 80% un autre objet de la même table. Mais comme je calcule le taux de recouvrement à partir de la géométrie de l'intersection, j'ai deux fois le résultat dans mon select (une fois avec ID=1,ID=2 et une fois avec ID=2,ID=1).
Ma requête :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SELECT                                                          /*+ ordered */
      E.GID,
       E."nom" AS NOM_EMPRISE,
       E."compleme",
       E."code_arc",
       E."commune",
       E2.GID,
       E2."nom" AS NOM_EMPRISE,
       E2."compleme",
       E2."code_arc",
       E2."commune"
  FROM E_EMPCTR E, E_EMPCTR E2
 WHERE     SDO_ANYINTERACT (E2.GEOMETRY, E.GEOMETRY) = 'TRUE'
       AND SDO_GEOM.
           SDO_AREA (SDO_GEOM.SDO_INTERSECTION (E.GEOMETRY, E2.GEOMETRY, 1),
                     1) >= 60 * SDO_GEOM.SDO_AREA (E.GEOMETRY, 1) / 100
       AND E.GID != E2.GID;

pour l'instant j'ai donc comme résultat :

E.GID E.NOM_EMPRISE E1.GID E1.NOM_EMPRISE
----------------------------------------------------------------------------------------
2460 .ALLEE DES CHAMPENOIS.PROGRAMME 2009. 2056 .ALLEE DES CHAMPENOIS.
2056 .ALLEE DES CHAMPENOIS. 2460 .ALLEE DES CHAMPENOIS.PROGRAMME 2009.
....

Comment faire pour n'obtenir qu'une ligne puisqu'il s'agit de paire unique ?

D'avance, merci,

PS. Quelqu'un sait comment mettre en forme des tableaux dans les messages que l'on poste sur le forum ?

[orafrance]

Tu peux probablement t'en sortir la fonction analytique RANK OVER() sinon FIRST

[H.ile]

Merci orafrance.
Mais je ne saisis pas en quoi ces expressions vont me permettre de purger mon résultat des couples en double ({A,B} et {B,A}).
J'ai essayé le rank over, mais cela ne me renvoie pas la même valeur pour la ligne {A,B} et {B,A}.
Quant au first, il semble être utilisable avec une fonction d'aggregat, que je n'utilise pas (puisque ce n'est pas une moyenne ou un min d'un des id que je souhaite récupérer).
Ai-je mal compris quelque chose ?
D'avance, merci,

[Waldar]

Changez votre critère :

Code :

 AND E.GID != E2.GID;

En :

Code :

 AND E.GID > E2.GID;

[H.ile]

Aloha,

Bon je m'en suis sorti autrement, en organisant les emprises selon leur aire et en ne renvoyant de résultat que pour l'emprise ayant la plus grande dans le couple.

Maintenant je m'intéresse à d'autres objets toujours en relation avec des emprises (des polygones, des surfaces). Il s'agit de tronçons. Et si ma requête est correcte, je m'étonne de ne pas avoir de résultat au bout d'une heure de traitement.

Quelqu'un a-t-il une idée ?

D'avance, merci,

Code :

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
SELECT                                                             /*ORDERED*/
      S.GID,
       S.ID_EMPRISE,
       S.NOM_EMPRISE,
       S.LG,
       S.MAX_LG,
       R_VOIE.CODCOM,
       R_VOIE.CODRUE
  FROM    (   (SELECT T.GID,
                      E.GID AS ID_EMPRISE,
                      E."nom" AS NOM_EMPRISE,
                      E."commune" AS COMMUNE_EMPRISE,
                      SDO_GEOM.
                      SDO_LENGTH (
                         SDO_GEOM.
                         SDO_INTERSECTION (E.GEOMETRY, T.GEOMETRY, 0.1),
                         0.1)
                         AS LG,
                      MAX (
                         SDO_GEOM.
                         SDO_LENGTH (
                            SDO_GEOM.
                            SDO_INTERSECTION (E.GEOMETRY, T.GEOMETRY, 0.1),
                            0.1))
                      OVER (PARTITION BY E.GID)
                         AS MAX_LG
                 FROM E_EMPCTR E, R_TRONCO T
                WHERE SDO_ANYINTERACT (E.GEOMETRY, T.GEOMETRY) = 'TRUE'
                      AND SDO_RELATE (
                             E.Geometry,
                             T.Geometry,
                             'mask=covers+OVERLAPBDYDISJOINT+CONTAINS') =
                             'TRUE'-- AND E.GID = 1239
              ) S
           INNER JOIN
              R_TRONCO_RELATION
           ON S.GID = R_TRONCO_RELATION.GID_D)
       INNER JOIN
          R_VOIE
       ON (    R_TRONCO_RELATION.GID_A = R_VOIE.GID
           AND R_TRONCO_RELATION.CLASS = 'R_VOIE'
           AND R_TRONCO_RELATION."NAME" = 'referent')
 WHERE LG = MAX_LG

[remi4444]

Pour tout ce qui est performance de requête, on ne peut rien dire si tu ne fournis pas beaucoup plus de renseignements, à savoir:

- La volumétrie (en gros) des tables concernées
- La volumétrie des résultats attendus
- Si la 2ième est toute petite par rapport à la première, alors le ou les critères qui seront les plus discriminants
- les index
et surtout: Le plan d'exécution!

[H.ile]

Aloha
La table E_EMPCTR fait 2600 lignes, la table R_TRONCO, 7000, la table R_VOIE, 3000. Tout ça à la louche. J'aimerai un résultat par ligne de E_EMPCTR où le code rivoli est nul, donc en gros 1200 lignes.
Les index spatiaux ont été reconstruits. Y a-t-il d'autres index qu'il me faudrait reconstruire ?
Ci dessous une capture d'écran du plan d'exécution.
Je ne vois toujours pas ce qui pêche...

[orafrance]

et sans le hint ?

[H.ile]

Envoyé par orafrance

et sans le hint ?

gné ?
sans le "/*ORDERED*/" ?
Bah c'est exactement le même plan d'exécution...

[Waldar]

Tel qu'il est écrit, c'est juste un commentaire, pas un HINT.

[remi4444]

Bon, la bonne nouvelle, c'est que l'optimiseur a bien détecté que ça allait être très coûteux, il ne reste plus qu'à remettre les bon index et les bonnes jointure pour que ça arrête de faire des acces-full de partout!

[orafrance]

Envoyé par Waldar

Tel qu'il est écrit, c'est juste un commentaire, pas un HINT.

En effet, au temps pour moi

[remi4444]

Sinon, on vois que le domain-index a un coût assez faramineux! je pense qu'il faut voir de ce coté là, mais tu dois être plus spécialiste que nous sur ce point précis....