Bonsoir,

Je dois faire le site d'un restaurant. Pour résumer, ce site proposera au client un aperçu de l'ensemble des plats et la possibilité de commander en ligne.
Parmi les plats on peut distinguer (je donne quelques exemples) : pâtes en sauces (sous entendus plusieurs type de pâtes et plusieurs sauces), soupes, sandwichs (plusieurs catégories de sandwichs) et entrées (salades pré-faites ou à composer avec des ingrédients au choix).


J'étais en train de faire mon schéma relationnel quand je me suis posé plusieurs question :

> Est ce qu'il est judicieux de faire une unique table "produits" qui va donc tout regrouper ou créer plusieurs tables comme ("sandwichs" et "cat_sandwichs") , ("types_pates" et "sauces_pates") etc.

> Il sera nécessaire de gérer les commandes en interne. Je vais donc créer une table "clients" et "commandes". Entre ces 2 tables il y a une cardinalité M:N, mon ancien prof de PHP m'a expliqué qu'il est conseillé de décomposer une relation M:N en deux relation de type 1:N... mais je ne sais plus pourquoi ^^'
Est ce que quelqu'un pourrait aussi m'éclairer sur ce point ?

merci d'avance
Cdt,

Sidguia

Si 2 relations sont reliées par M:N , c'est logique de créer une 3ème relation qui fera justement ce lien.

J'ai une table A contenant des infos
J'ai une table B contenant d'autres infos

Chaque entrée de A peut être en relation avec chaque entrée de B
Si un A n'avait qu'un seul B, un champ B dans A suffirait. Et inversement si B n'avait qu'un seul A.
Mais toi c'est M:N donc tu ne connais pas d'avance combien chaque A aura de B ni combien chaque B aura de A.
Donc tu dois passer par une table intermédiaire qui fera la liaison entre un A et un B, les 2 champs formant une clé primaire.

La présence d'une ligne dans cette table intermédiaire indiquera que l'élément A est en relation avec l'élément B.
C'est l'exemple typique d'une gestion d'amis.

Sinon pour répondre plus à même à ta question. Je pense qu'il peut être intéressant de définir tes entités.
Une entité doit avant tout permettre d'éviter la redondance des données ! A toi de voir donc ce qu'il est nécessaire de créer comme entité.

Merci pour ton explication claire

Les entités comme "sandwichs", "soupes", "entrées" ont les mêmes attributs à savoir : id, titre, description, visuel, prix.

Malgré cette répétition il est plus approprié de créer ces table ?

Pas forcément. A la vue des informations que tu donnes, je ferais:

Une table
- type_produits, avec en entrée (sandwich, soupe, salade, etc)
- produits, contenant une référence à type_produit et qui donne plus d'information sur le produit (exemple: salade niçoise avec un référence au type_produit des salades)
- menus, tous les noms des menus qui existent s'il y a une carte de menus spécifiques (composition des menus imposées ou libres ? à voir)

Après selon les informations, prix peut se retrouver dans type_produits ou dans produits. La question que tu dois te poser pour chaque champ, c'est:
"Est ce que mon information est identique pour chacun de mes type_produit ou non ?"
Pour reprendre le prix, est ce que tous les sandwich auront le même prix ? Etc etc.
Si 2 produits du même type n'ont pas le même prix, alors l'information prix devra se trouver dans la table produits.
Et tu fais la même chose avec les autres informations.

Hum... ok je vois le raisonnement.

Autre petite question : pour les types de pâtes, les sauces, les différents types de sandwichs, les ingrédients pour la composition des salades, je dois créer pour chacun d'eux une table ?

Et la table produits contiendra des références aux table citées précédemment ?

Non certainement pas, ce sont des type de produit ça, les pates. Et c'est dans la table produits que tu mettrais carbonara, bolognaise etc

Bonjour,

J'en profite, je travaille sur un programme de gestion de caisse, et étant donné que ce programme sert dans plus d'un établissement on peu voir apparaître plein de cas intéressant.

Par exemple des offres promotionnelles, des prix différents en fonction de type de client, des tva qui change en fonction des produit ou même en fonction du "mode de consommation" (à consommer sur place, à emporter).

Bref, évidement si tu dois faire l'application pour un seul client tu ne dois pas réfléchir à tout sa (sauf s'il le demande ) mais si tu vise éventuellement plusieurs clients je te suggère de réfléchir sérieusement.