Discussion :

[zebullon]

Bonjour amis développeurs,

je vais vous exposer mon probleme que je situe plutôt de l'ordre conceptuel.
Disons que j'ai une table ELEMENT (id_element,lib_element), chaque élément peut être affecté à un groupe (id_groupe,lib_groupe) voir à plusieurs groupes. Chacun de ces groupes
pouvant être aussi constitués de groupe et éléments (on pourrait parler de groupe de groupe) et ceci à l'infini
je ne vois pas comment je pourrais concevoir mes tables sachant que j aimerai bien utilise la Modélisation par méta données et connaitre le niveau du groupe ex: groupe simple alors niveau 1 , groupe de groupe alors niveau 2 et ainsi de suite .
Si vous avez des idées, je suis preneur .

Merci d'avance

[adeppierraz]

Pour le schéma conceptuel de ce problème voir ClassDiagram.ppt.

J'ai supposé qu'un élément ou un groupe n'est enfant que d'un seul groupe. Remarquons que si ce n'était pas le cas (plusieurs parents) la notion de niveau n'est pas unique (il peut y avoir plusieurs niveaux, un par parent).

Le schéma de classe se traduit par le schéma relationnel (schéma de tables) suivant :
groupe (id_groupe, lib_groupe, id_parent)
element (id_element, lib_element, id_groupe)

Pour la notion de niveau, j'espérais qu'une vue sur groupe pourrait faire l'affaire. Malheureusement, ça nous donne une définition récursive que SQL ne peut pas accepter.

Bonne chance tout de même.

[fsmrel]

Bonjour,

Ce genre de problème en relation avec les nomenclatures et la récursivité a déjà fait l'objet d'échanges sur ce forum.

Voir notamment :

[Résolu] [MCD] Gestion d'une nomenclature et des ensembles (problème soumis par Corben).

En descendant au niveau SQL, des SGBD comme Oracle ou DB2 vous donnent tous les renseignements (certes, il faut passer au moins un couple d'heures de lecture attentive...)

------------------------------
Oracle Database SQL Reference

http://www.oracle.com/pls/db102/to_t...ing+Started%29
http://download-uk.oracle.com/docs/c...b14200/toc.htm

http://download-uk.oracle.com/docs/c...102/b14237.pdf

mots clés dans Oracle : connect by, recursive

------------------------------
DB2

http://www-306.ibm.com/software/data...manualsv9.html

ftp://ftp.software.ibm.com/ps/produc...S/db2s1e90.pdf
ftp://ftp.software.ibm.com/ps/produc...S/db2m2e90.pdf

mots clés dans DB2 : Common-table, With, Recursive

[zebullon]

merci pour vos différentes réponses.
Effectivement j'avais déja planché sur la récursivité mais ceci est très couteux au delà du 4ème niveau de plus elle n'est pas assuré par tous les sgbdr d'où mon attrait pour la représentation intervallaire .
Encore merci pour ceux qui ont laissé quelques neurones

[fsmrel]

Bonjour Zebullon,

j'avais déja planché sur la récursivité mais ceci est très couteux au delà du 4ème niveau

Dans un contexte relationnel, le coût d'une requête peut varier énormément : selon la façon dont on la code, selon la présence des index qui vont bien, une requête qui peut prendre 10 millisecondes peut aussi prendre des heures si on n'a pas effectué les réglages qui vont bien.

Par exemple, avec Oracle, si l’on veut transformer des balayages de tables rédhibitoires en traversées verticales d’index, il faut avoir en tête cet avertissement quand on se lance dans le récursif :

"If the WHERE predicate contains a join, Oracle applies the join predicates before doing the CONNECT BY processing".

Procéder au réglage des requêtes fait partie du jeu (maîtriser d’abord l'instruction EXPLAIN ou son équivalent selon le SGBD)...

Personnellement, j'ai effectué des requêtes récursives sur des tables de 500 000 lignes, pour passer d'un temps de 5 minutes à 100 millisecondes après réglages.