Discussion :

[Selenn]

Bonjour,

Petite question assez simple je suppose mais elle me pose problème.

Je dois construire une BDD pour lister les ingrédients nécessaires à la réalisations de diverses recettes/menus.

Les recettes peuvent nécessiter qu'au préalable, une autre recette soit réalisée, avec elle-même ses ingrédients etc ... Au final, je peux avoir jusqu'à 5 niveaux de "production". c'est à dire qu'une recette peut nécessiter qu'une autre recette soit réalisée pour l'un des ingrédients, qui elle-même peut demander que d'autres recettes soient réalisées, etc, sur 5 niveaux.

Ma question est la suivante :
Puis-je faire une table unique regroupant toutes les recettes, et appeler dans mes requêtes la même table successivement.

En clair, peut-on faire quelque-chose qui ressemble à des appels récursifs sur une unique table ? Ou serait-il préférable que je fasse 5 tables de recettes, une par "niveau de production", et que j'obtienne la liste des ingrédients/recettes nécessaires par croisement des tables ?

Au début j'ai cru que mon histoire se rapprochait beaucoup d'un organigramme, sauf que là, toutes les recettes sont potentiellement utilisables comme "ingrédient" d'une autre recette. Ca fait des sacrés noeuds dans ma tête et je n'arrive pas à construire ma base.

Merci d'avance pour vos réponses :-)

[GreatDeveloperOnizuka]

Code :

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

1
2
3
SELECT *
FROM Table AS T1
WHERE EXISTS (SELECT * FROM Table AS T2 WHERE T1.NomColonne = T2.NomColonne)

Je crois qu'il faudrait faire une sous requête de ce type par exemple pour les appels récursives.

[Eric93]

Moi j'ai fait le même système pour un menu dynamique, dans ma table j'ai un élément du menu, avec une colonne parent qui contiend l'id du menu supérieur (ou 0 pour le menu principal).

Puis après j'utilise des fonction PHP récursives (qui font de simple requête) pour gérer cette table. Chaque niveau de la fonction fait une requete, puis rapelle la fonction avec les paramètre récupéré dans la requête, qui refait une requete, etc..

Les sous requete ne sont pas reccursive du tout, à moins de la construire dynamiquement avec autant de sous requete que tu as de niveau. Trop compliqué et lourd.

Ton problème est de bien concevoir ta table, car dans ton exemple, les element peuvent avoir plusieurs parent, mais c'est faisable.

[fallo]

si on dit qu'une recette est un ingredient
alors pour faire un ingredient, il faut dans certains cas un ensemble d'autres ingredient, donc certains ingredient (les feuilles de notre arbre de recettes) n'ont pas d'ingredients.


donc on peut utiliser les CTE recursive.

la faq adaptée :
http://sqlpro.developpez.com/cours/s...cte-recursives

bon courrage !

[Eric93]

Moi je ferais un truc du genre

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
Table Ingrédient/Recette 
--   ----------------         
ID   TYPE DESCRIPTION         
--   ----------------         
1     I   Sel                 
2     I   Poivre              
3     I   Crème fraiche       
4     I   Escaloppe           
5     R   Sauce blanche       
6     R   Escaloppe à la crème
                         
Table de liens           
--   ---------           
ID   ID PARENT           
--   ---------           
5    1                   
5    2                   
5    3                   
6    4                   
6    5  

La table de lien indique par exemple que la recette Escaloppe à la crème à besoin d'un ingrédient Escaloppe et d'une autre recette Sauce blanche qui à elle même besoin de 3 ingrédient Sel, Poivre et Crème fraiche.

Puis après j'utiliserais des fonction PHP récursives (contenant de simple requêtes) pour gérer tout ca

[Selenn]

Merci à vous, je vais explorer ces pistes ...

Le fond de mon problème, c'est que je ne sais pas si je dois traiter le problème "un enfant peut avoir plusieurs parents et être lui même parent de plusieurs enfants" au niveau de la création de la base, ou au niveau des requêtes ...

Merci pour vos infos :-) Ta solution me plait bien Eric93

[Eric93]

Je connaissais pas la récursion en SQL, interessant ce lien, moi je gère par PHP que je maitrise mieu, ca doit se valoir. Question de choix

[Eric93]

Le fond de mon problème, c'est que je ne sais pas si je dois traiter le problème "un enfant peut avoir plusieurs parents et être lui même parent de plusieurs enfants" au niveau de la création de la base, ou au niveau des requêtes ...

Dans les 2 cas c'est au moment de la création de la base, après tu peux le traiter par Requete reccursive (lien de fallo), je connaissais pas, ou par fonction récursives en PHP.

Vu que chaque parent peux avoir plusieurs enfants et chaque enfant peux avoir plusieurs parents, tu pense pas que tu puisse faire ca en une table, il t'en faut 2, a moins de mettre les informations de la première table dans la seconde, mais t'auras redondance d'information (moi j'ai mis que le titre de la recette, mais si ta 2 page de textes pour expliquer la recette, ces 2 page se retrouveront dans chaque lien, pas bon).

[SQLpro]

Je connaissais pas la récursion en SQL, interessant ce lien, moi je gère par PHP que je maitrise mieu, ca doit se valoir.

Pas vraiment... Raisonnez en terme de performances et de volume des données et vous verrez que cela n'a rien à voir !

A +

[Eric93]

C'est sur que SQLpro préfère la méthode SQL, il défend son bifteck , d'autant plus qu'il est l'auteur de ce tuto, d'ailleur fort interessant.

C'est sur qu'en terme de performance, c'est surement plus rapide, mais ca dépend des volumes, si c'est pour de petite base, ca change rien.

Par contre en terme de maintenance et de souplesse, ca se discute.

[vmolines]

La performance a toujours un lien avec le volume.

Ce sera tout de même plus performant avec un faible volume. La seule différence c'est que le gain de temps sera humainement moins perceptible.

[Eric93]

Quand je dis ca change rien, c'est que ca sert pas forcément de chercher la performance pour gagner quelques micro-seconde sur une requête.

Faut tenir compte de la complexité du code, ca vaut pas forcement le coup

[al1_24]

Il faut aussi raisonner en client / serveur.
Avec une requête récursive, tout le traitement est effectué sur le SGBD, seul le résultat est retourné au client applicatif, en un seul flux.
Avec un traitement en PHP, une partie du traitement est effectuée sur le serveur d'application et de multiples flux sont échangés entre celui-ci et le SGBD.

[Eric93]

De multiple flux mais avec des requêtes très simples.

Je conteste pas que coté performance c'est plus rapide de faire directement en SQL, je dis que les performances pour gagner quelques micro-secondes c'est pas forcement utile, faut tenir compte d'autres critère, comme la lisibilité du code, la maintenance, et d'autres encore.

Tout le monde n'est pas PRO de SQL, et c'est quand même plus simple en php.

[al1_24]

Tout le monde n'est pas PRO de SQL, et c'est quand même plus simple en php.

On peut aussi planter un clou en tapant dessus avec une clé anglaise, mais avec un marteau c'est plus efficace.

[Eric93]

Je suis pas d'accord, il existe plusieur facon de faire et chacune à ses avantages et inconvénient, c'est souvent le cas en informatique, faut peser le pour et le contre et trouver un juste milieu, on peut même utiliser les 2, tout dépend de ce que l'on veux faire.

Je comprend pas ceux qui sont bornés sur une seule méthode, faut être ouvert.

Moi je connaissais pas la récursivité en SQL, j'ai lu le tuto avec beaucoup d'interet. Je l'utiliserais peut-être.