Format d'une DB (Théorie/Conseil)?

Bonjour tout le monde,

Je me trouve confronté à un petit problème de conception pour une BDD destinée à stocker des recettes de cuisines. De manière synthétique, nous avons 2 tables: dbIngr qui contient les ingrédients et dbRecet qui contient hum les recettes. Mon problème est le lien entre les deux tables. Autrement dit, comment lier dbRecet à dbIngr de manière intelligent et optimale.

Ma première idée était d'avoir une colonne dans dbRecet qui contiendrai l'ID de l'ingrédient (index de dbIngr en fait). Mais j'ai peur que cette solution soit un peu uzine à gaz: si une recette contient 10 ingrédients, j'aurai 10 entrées dans dbRecet pour la même recette (avec une superbe redondance d'informations). De plus, je dois étendre la clé pour différencier les 10 entrées, ce qui parait-il n'est pas forcément le mieux.

Une autre idée était de mettre un nombre donné de colonnes dans dbRecet pour les ingrédients, par exemple 15 colonnes, qui contiendraient les ID des ingrédients. Mais ici, si une recette ne possède que 5 ingrédients, nous avons 10 colonnes vides et ne serviront jamais à rien. Par contre, je n'ai pas de redondances d'informations, ni plusieurs entrées pour une même recette.

Si vous avez un avis ou une critique, n'hésitez pas. Toute aide est la bienvenue. Au passage, cette DB fera partie d'un projet de site web gratuit. Donc, je ne vous fais pas l'aumône pour ensuite me faire des sous sur vos connaissances.

Ken.

Salut

moi perso j'opte pour la 1ere solution
un colonne id ingrédient dans la table recette, si c bien géré ( c loin d'etre dure) ça sera pas dutout une usine a gaz, c le principe d'un forum, j'ai ça sur mon site et meme avec 200 question et 1000 réponses y a pas de problemes.

Index bien tes champs et le tours est joué (l'indexation sert a rendre plus rapide la recherche dans ces champs)

++

--> http://www.kame-house.org <--
La plus grosse base de données sur les dessins animés des années 80
Site gratuit et sans pub


-------------------------------
Réponse au message :
-------------------------------

> Bonjour tout le monde,
>
> Je me trouve confronté à un petit problème de conception pour une BDD destinée à stocker des recettes de cuisines. De manière synthétique, nous avons 2 tables: dbIngr qui contient les ingrédients et dbRecet qui contient hum les recettes. Mon problème est le lien entre les deux tables. Autrement dit, comment lier dbRecet à dbIngr de manière intelligent et optimale.
>
> Ma première idée était d'avoir une colonne dans dbRecet qui contiendrai l'ID de l'ingrédient (index de dbIngr en fait). Mais j'ai peur que cette solution soit un peu uzine à gaz: si une recette contient 10 ingrédients, j'aurai 10 entrées dans dbRecet pour la même recette (avec une superbe redondance d'informations). De plus, je dois étendre la clé pour différencier les 10 entrées, ce qui parait-il n'est pas forcément le mieux.
>
> Une autre idée était de mettre un nombre donné de colonnes dans dbRecet pour les ingrédients, par exemple 15 colonnes, qui contiendraient les ID des ingrédients. Mais ici, si une recette ne possède que 5 ingrédients, nous avons 10 colonnes vides et ne serviront jamais à rien. Par contre, je n'ai pas de redondances d'informations, ni plusieurs entrées pour une même recette.
>
> Si vous avez un avis ou une critique, n'hésitez pas. Toute aide est la bienvenue. Au passage, cette DB fera partie d'un projet de site web gratuit. Donc, je ne vous fais pas l'aumône pour ensuite me faire des sous sur vos connaissances.
>
> Ken.

Je t'avoue que c'est la solution que je préfère, mais la redondance d'infos me parait vraiment problématique. Dans mon post, je n'ai pas précisé que la table des recettes contenait un champs de type BLOB permettant de stocker la préparation de la recette (le modus operandi si tu préfères).

Si j'utilise la 1ère solution, il est préférable que je place la préparation autre part, soit dans une table indépendante soit dans un fichier plat. Si j'utilise une table indépendante, est-ce que le fait de devoir lire 3 tables différentes pour afficher une seule recette ne va pas jouer fortement sur les performances?

Quoiqu'il en soit, merci de ta réponse.

A+

-------------------------------
Réponse au message :
-------------------------------

>
> Salut
>
> moi perso j'opte pour la 1ere solution
> un colonne id ingrédient dans la table recette, si c bien géré ( c loin d'etre dure) ça sera pas dutout une usine a gaz, c le principe d'un forum, j'ai ça sur mon site et meme avec 200 question et 1000 réponses y a pas de problemes.
>
> Index bien tes champs et le tours est joué (l'indexation sert a rendre plus rapide la recherche dans ces champs)
>
> ++
>
> --> http://www.kame-house.org <--
> La plus grosse base de données sur les dessins animés des années 80
> Site gratuit et sans pub

tu peux juste faire 3 tables

1 table recette qui contient la recette, la préparation
1 table ingrédiant avec la liste entiere des ingrédients
1 table de jointure avec par exemple 2 champs id recette et id ingrédient

id_recette | id_ingrédient
==================
1 | 2
1 | 12
1 | 9
1 | 5


Ce ki veut dire ke pour la recette 1 faut l'ingrédient 2, 12, 9 et 5

On aura parler de tout sur ce forum lol

++

--> http://www.kame-house.org <--
La plus grosse base de données sur les dessins animés des années 80
Site gratuit et sans pub


-------------------------------
Réponse au message :
-------------------------------

> Je t'avoue que c'est la solution que je préfère, mais la redondance d'infos me parait vraiment problématique. Dans mon post, je n'ai pas précisé que la table des recettes contenait un champs de type BLOB permettant de stocker la préparation de la recette (le modus operandi si tu préfères).
>
> Si j'utilise la 1ère solution, il est préférable que je place la préparation autre part, soit dans une table indépendante soit dans un fichier plat. Si j'utilise une table indépendante, est-ce que le fait de devoir lire 3 tables différentes pour afficher une seule recette ne va pas jouer fortement sur les performances?
>
> Quoiqu'il en soit, merci de ta réponse.
>
> A+
>
> -------------------------------
> Réponse au message :
> -------------------------------
>
> >
> > Salut
> >
> > moi perso j'opte pour la 1ere solution
> > un colonne id ingrédient dans la table recette, si c bien géré ( c loin d'etre dure) ça sera pas dutout une usine a gaz, c le principe d'un forum, j'ai ça sur mon site et meme avec 200 question et 1000 réponses y a pas de problemes.
> >
> > Index bien tes champs et le tours est joué (l'indexation sert a rendre plus rapide la recherche dans ces champs)
> >
> > ++
> >
> > --> http://www.kame-house.org <--
> > La plus grosse base de données sur les dessins animés des années 80
> > Site gratuit et sans pub
>
>

Tu viens de me remettre en mémoire un trèèès vieux cours sur les DB en parlant de table de jointure. Pas crétin du tout.

Merci beaucoup pour le coup de main.

K.


-------------------------------
Réponse au message :
-------------------------------

>
> tu peux juste faire 3 tables
>
> 1 table recette qui contient la recette, la préparation
> 1 table ingrédiant avec la liste entiere des ingrédients
> 1 table de jointure avec par exemple 2 champs id recette et id ingrédient
>
> id_recette | id_ingrédient
> ==================
> 1 | 2
> 1 | 12
> 1 | 9
> 1 | 5
>
>
> Ce ki veut dire ke pour la recette 1 faut l'ingrédient 2, 12, 9 et 5
>
> On aura parler de tout sur ce forum lol
>
> ++
>
> --> http://www.kame-house.org <--
> La plus grosse base de données sur les dessins animés des années 80
> Site gratuit et sans pub