Discussion :

[arutan]

Bonjour à tous !

Je suis nouveau sur ce forum en tant que posteur... jusqu'à maintenant je profitais de toutes ses ressources...
Mais je fait le pas de poster ce premier message parceque je butte sur un problème en SQL.
Je sais pas si cette rubrique est la bonne mais voilà mon problème...

Je possède une structure de base de données sous la forme d'un arbre. Voici le principe :
Je possède trois tables A, B et C qui sont hiérarchiques.
Des éléments C sont contenus dans des éléments B.
Et des éléments B sont contenus dans des éléments A.

Dans deux autres tables j'effectue les association entre ces niveaux.

Ci joint un schéma illustrant les propos.

Je voulais savoir comment éffectuer la requête permettant de trouver à partir d'un élément quelconque (A, B ou C) tous les éléments entrant dans sa chaîne.

Exemples :
# à partir de C2, je voudrais avoir les résultats suivants :
A1 | B2 | C2
A1 | B3 | C2
A2 | B3 | C2

#à partir de B4, les résultats :
A2 | B4 | C5
A2 | B4 | C6
A3 | B4 | C5
A3 | B4 | C6

Vous l'avez compris... de même à partir d'un élément Ax...
En fait la méthode que j'ai trouvé est de combiner avec la clause IN des sous requete SELECT mais je sais pas si c'est la meilleure méthode...

Au passage j'avais une autre question par curiosité (je sais pas si je dois ouvrir un nouveau post alors je continu ici...)

Donc, aAccesoirement je voudrais aussi savoir quel requête permettait d'obtenir le nom de la table à laquelle appartient un élément.
Bon là avec les noms que j'ai donné c'est évident, mais dans la réalité c'est pas A2, A3 etc...

Je sais que l'on peut éventuellement éffectuer une rêquete dans chacune des tables et de mémoriser laquelle retourne un résultat.
Mais existe-t-il une fonction qui donne le nom de la table d'un élément lorsque l'on effectue une recherche dans plusieurs table ? (un peu comme pour l'obtention du nom d'un champ en php avec mysql_num_fields()).

Merci beaucoup d'avance.
Et vive le partage !

[SQLpro]

1) il est franchement pas bon d'avoir modélisé votre arbre sur 3 table. Une seule aurait suffit avec une auto référence (plus de cohérence et intégrité garantie). Maintenant il ne vous reste plus qu'a faire une vue pour synthéstiser toute ces info.
2) vous pouvez utiliser des requêtes récursives via la CTE pour traiter les parcours d'arbre. Voir l'article que j'ai écrit sur ce sujet : http://sqlpro.developpez.com/cours/s...te-recursives/
3) si votre SGBD ne supporte pas les CTE (en vigueur depuis la norme SQL de 1999), alors représentez votre arbre sous forme intervallaire. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/arborescence/

A +

[arutan]

Merci pour les liens... je vais m'y pencher...
Sinon pour le fait d'avoir mis sur trois table.. cela s'explique parceque c'est comme ça que j'ai appris à faire à l'école.
" Principe des sgbd : Chaque table ne comporte que les éléments. Puis les associations sont éffectués uniquement par les clés.
Le but -> Si on modifie un item, seule une entrée est affecté. "
Enfin c'est ce que l'on m'a appris.
De plus ici, c'est aussi justifier (peut-être que j'aurai dû le préciser) par le fait que les éléments de A, B ou C ne sont pas entrés en même temps et que les associations sont faites ultérieurement (et peuvent être modifié...)

Mais cela reste un cas d'école et je ne possède pas du tout votre expertise pour savoir si avec une grosse base de données ce système reste efficace.

Autre chose : J'ai éffectué mes requêtes sans jointures (enfin, sans les clause spécifique de jointure "XXX JOIN") mais avec le principe de l'égalité sur les champs... que vous intituler "Premiers essais de jointure" dans votre cours.
J'ai éffectués cela juste avec une série d'imbrication de SELECT avec la clause IN.
Pensez-vous que c'est un bricolage et faut-il plutôt utiliser des opérations de jointures normalisé ?

Dans tout les cas je vais me pencher sur vos liens. Merci encore.

PS : Je suis sous MySQL et PHP (plateforme wamp)

[SQLpro]

Pensez-vous que c'est un bricolage et faut-il plutôt utiliser des opérations de jointures normalisé ?

Oh que oui... C'est du bricolage. Même si SQL supporte beaucoup de chose, c'est un vrai langage complet (admet la récursivité, mais MySQL ne sait pas le faire) et nécessite un solide apprentissage !

A +

[arutan]

Je viens de lire votre article sur les CTE (compte tenu mon niveau je viens plutôt de pré-lire...).
J'ai un peu saisi le principe des CTE, mais quand vous dites que les CTE permettent de résoudre tout problème (bien modélisé, bien sur..) en une seule requete... que signifie en une seule requete ?
Il n'y a pas qu'un seul SELECT... FROM dans le dernier exemple par exemple..

Concernant la représentation intervallaire des arborescences.. je l'ai juste survolé mais (au vue des images, lol..) je pense que c'est ce qui conviendrait...

En fait j'ai aussi peut-être mal exprimée les possibilités que j'entrevoyais avec mes trois tables... Il s'agit par exemple de trouver à partir d'un élément C tout les éléments frères (c'est à dire tout les éléments C qui appartiennet au même élément B) ou tout les cousins aussi (tout les éléments C qui appartiennent au même élément A)
Un exemple :
les frères de l'item C3 sont l'item C1 et C2 (de par B2)
le frère (unique) de l'item C5 est l'item C6 (de par B4)
tandis que les cousins de l'item C5 seront :
C7 et C9 (de par A3 et B5)
C8 et C10 (de par A3 et B6) mais aussi
C2 et C4 (de par A2 et B3)

En fait le principe est de remonter et de redescendre l'arbre à partir d'un élément de hiérarchie la plus faible..
L'image attaché présente ce principe.

pour cela j'ai posé quatre requete SELECT de base :
Req1 pour obtenir les éléments B à partir d'un C
Req2 pour obtenir les éléments A à partir d'un B
Req3 pour obtenir les éléments B à partir d'un A
Req4 pour obtenir les éléments C à partir d'un B

Ensuite j'effectue l'imbrication
Req1 IN Req2 IN Req3 in Req4

Le problème c'est que puisque j'ai deux tables d'associations j'obtiens des opérations de jointure pas très propres du tout...
A titre d'information voilà le code pour cette requete :

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
 
SELECT DISTINCT A.Name
FROM Element C, Type B, AssocTypeElem
WHERE B.Name
IN (
 
	SELECT DISTINCT B.Name
	FROM Famille A, Type B, AssocFamType
	WHERE A.Name
	IN (
 
		SELECT DISTINCT A.Name
		FROM Famille A, Type B, AssocFamType
		WHERE B.Name
		IN (
 
			SELECT DISTINCT B.Name
			FROM Element C, Type B, AssocElemType
			WHERE C.Name = 'xxxxx'
			AND C.Id = IdElem
			AND B.Id = IdType
			)
		AND A.Id = IdFam
		AND B.Id = IdType
		)
	AND A.Id = IdFam
	AND B.Id = IdType
	)
AND C.Id = IdElem
AND B.Id = IdType

A votre avis, pour réaliser proprement ce genre de requête quel sera le plus élégant (mais aussi rapide, sûr , normalisé etc... Bref, sous MySQL vous auriez fait comment..) :
- Passer aux CTE ? (avec l'apprentissage qui faut... (j'ai pas compris si MySQl supporte les CTE ou pas..)
- Utiliser les arbre intervallaires ? (il faut que je lise en détail mais je crois avoir vu que ce genre de requête était possible justement...)
- Refaire le bricolage mais avec des opérations de jointures normalisé ?

Merci encore pour votre avis éclairé

[SQLpro]

JA votre avis, pour réaliser proprement ce genre de requête quel sera le plus élégant (mais aussi rapide, sûr , normalisé etc... Bref, sous MySQL vous auriez fait comment..) :
- Passer aux CTE ? (avec l'apprentissage qui faut... (j'ai pas compris si MySQl supporte les CTE ou pas..)
- Utiliser les arbre intervallaires ? (il faut que je lise en détail mais je crois avoir vu que ce genre de requête était possible justement...)
- Refaire le bricolage mais avec des opérations de jointures normalisé ?

1) MySQL ne supporte pas les CTE et reste assez pauvre en terme de SQL. Préférez PostGreSQL ! Surtout que depuis le rachat de MySQL par Oracle, il semblerait que son avenir soit incertain...
2) Pour les représentation intervallaire, ceci suppose que tout est dans la même table.
3) Si votre arbre est à profondeur constante, alors vous pouvez utiliser des jointures externes entre vos tables, mais ce sera toujours peu performant.

La première optimisation consiste à faire un modèle de données qui soit normalisé et corresponde à votre besoin. Pourquoi restez vous obnubilé sur vos trois tables alors que visiblement cela ne répond pas correctement à votre problème ? Voulez vous sciemment pourrir d'entrée de jeu les performances par un modèle bricolé ?

A +