onjour, je viens vers vous aujourd'hui car on est sur un site commerçant, pour un restaurateur. (on est en stage)
Notre professeur nous a dit que notre schéma de base de donné était erroné et qu'il fallait faire des tables de jointures entre le panier et les condiments.
Qu'en pensez-vous, et comment faire ? Car faire des requêtes avec des INNER JOIN pas de soucis mais une table de jointure ...
Pas vraiment non et lors des projets les BDD était déjà sur papier.
Par exemple, comment se fait-il qu'il y ait un lien vers "sandwich" depuis "panier" ET "menu" ?
Cela est normal car un menu est composé d'un sandwich, mais on peut également commander seulement un sandwich.
Donc aujourd'hui je ne voie vraiment pas comment faire des TABLES de jointure, sur internet il parle seulement de jointures, et idem dans mon livre sur le Sql. On est un peu perdu...
Bon, concrètement, il faut une table de "relation" quand deux entités peuvent être liées dans les deux sens : dans ton exemple, ce n'est pas logique de n'avoir qu'un sandwich dans un panier, tu devrais pouvoir en mettre plusieurs. Il te faudrait donc une table avec simplement l'id du menu et l'id du sandwich.
Le vrai problème est que toutes la bdd est à revoir, tes colonnes de la table sandwich devraient être les valeurs d'une autre table "ingredients".
Il faut que tu réfléchisses un peu plus à partir des entités, puis du type de relations entre elles.
Tu ne devrais pas avoir des tables identiques : par exemple "frite", "boisson", "sandwich", "dessert" devrait être regroupés dans une table "article", en ajoutant une table "catégorie" et une colonne "id_categorie".
Ensuite tu n'as besoin d'une table de relation que pour les relations n,n, par exemple si on considère qu'une commande ne peut avoir qu'un utilisateur, tu supprimes la table "liste_commande" et tu fait le lien directement entre la table "commande" et la table "utilisateur".
Merci pour vos réponses. On essaye de comprendre mais c'est difficile.
Benzouye Je ne suis pas sur de bien comprendre ta question, je dirais via la table de jointure.
Philodick voici ma proposition, avec ce qu'on a réussie à comprendre. C'est là aussi qu'on s'aperçoit des énormes lacunes qu'on a...
Et un utilisateur peut avoir plusieurs commandes, c'est pour cela qu'on a fait une table de jointure, tu penses que c'est possible d'avoir plusieurs commandes sans table de jointure .
Ce que j'ai du mal à comprendre, c'est par où commencer quand on se pose la question d'une relation: " un article a une catégorie mais une catégorie peut avoir plusieurs articles " Dans qu'elle sens va la relation et qui possède la Foreign key ?
Dans ce nouveau diagramme, je n'ai pas fait de table de jointure est vraiment nécessaire du coup .
Chaque commande (donc chaque ligne de la table commande) ne peut en principe avoir qu'un utilisateur : donc pas de table de jointure mais une "clé étrangère" dans la table "commande" qui fait référence à l'id correspondant dans la table "utilisateur".
Même chose pour la table "panier", ce sont des relations 1,n.
Concrètement qu'on on a ce type de relation c'est à dire les lignes de la table "commande" n'ont qu'un utilisateur, mais chaque utilisateurs peut avoir bien sûr plusieurs commande. Dans ce cas, une clé étrangère dans la table "commande" suffit.
Si chaque commande pouvait avoir plusieurs utilisateurs, là on créerait une table de relation.
Je vous conseille de partir du MCD. Le logiciel JMerise, par exemple, va vous aider à modéliser vos entités et leurs relations et cardinalités ...
Là, vous n'y êtes pas du tout et cela empire ... En plus vous rajoutez des contraintes au fur et à mesure ... maintenant il y a des ingrédients à gérer ? Ce sont des suppléments ou les composants de recettes ?
Ok Philodick, je voie un peu plus clair, je vais réessayer avec ça.
Benzouye il y a toujours eu les ingrédients, ils sont les suppléments et les composants, car le restaurateur pourra ajouter des sandwichs par la suite.
Je reprends ce que nous ont dit notre professeur " il faut avoir une table de jointure/relations entre les condiments et le panier sinon on ne pourra pas avoir plusieurs frites ou sandwichs dans le panier"
Un panier peut avoir plusieurs sandwichs, mais un sandwich n'a qu'un panier, donc pourquoi une table de jointures est nécessaire si on suit ta logique Philodick ?
Je n'arrive pas a comprendre depuis vendredi pourquoi ils nous as dit cela, peut-être qu'il y a plusieurs manière de procéder ?!
Bon j'essaye de garder du courage et je retourne dessus.
Je pense que vous auriez du suivre un peu plus en cours Vous pouvez reprendre vos cours Symfony par exemple. Et bien sur que les relations ManytoMany on les as vu
- Edité par DenisSanchez2 22 juillet 2019 à 15:37:26
C'est la logique de la base de données qu'on ne comprend pas.
Comment crée une base de données à partie de rien
Je vous conseille la lecture du doc "Conception BDD" dans ma signature ... et l'utilisation d'un logiciel de modélisation MCD avant de faire vos tables, cela vous oblige à bien réfléchir à vos entités, leurs relations et leurs cardinalités ... Partir directement dans MySQL WorkBench c'est souvent passer à côté de choses importantes (à moins d'avoir un peu de bouteille dans la modélisation).
Jeffbzh3 a écrit:
il y a toujours eu les ingrédients, ils sont les suppléments et les composants, car le restaurateur pourra ajouter des sandwichs par la suite
Dans tous les modèles présentés avant il n'était jamais mention d'ingrédients ... Et cela complique un peu le modèle, puisque l'on parle alors de recettes ... Plusieurs ingrédients dans des quantités variables pour faire un produit (article) ...
Salut Denis, on avait commencé en effet par créer la base de donné depuis les entités d'abord. Cependant le résultat ne convenait pas à notre professeur, qui nous disait de rajouter des table de jointures…
Voici le résultat ci dessous. Aurais-tu une idée ?
C'est la logique de la base de données qu'on ne comprend pas.
Comment crée une base de données à partie de rien
Je vous conseille la lecture du doc "Conception BDD" dans ma signature ... et l'utilisation d'un logiciel de modélisation MCD avant de faire vos tables, cela vous oblige à bien réfléchir à vos entités, leurs relations et leurs cardinalités ... Partir directement dans MySQL WorkBench c'est souvent passer à côté de choses importantes (à moins d'avoir un peu de bouteille dans la modélisation).
Jeffbzh3 a écrit:
il y a toujours eu les ingrédients, ils sont les suppléments et les composants, car le restaurateur pourra ajouter des sandwichs par la suite
Dans tous les modèles présentés avant il n'était jamais mention d'ingrédients ... Et cela complique un peu le modèle, puisque l'on parle alors de recettes ... Plusieurs ingrédients dans des quantités variables pour faire un produit (article) ...
Merci Benzouye, on va regarder ça ! Merci pour vos réponses à tous, vous pouvez clore ce sujet et en ouvrirons un nouveau lorsque nous aurons fini de plancher dessus.
Effectivement je trouve que cette proposition va dans le bon sens.
En cours on a vu du codeFirst. Donc c'est pour ça que je vous disais de partir des Entités.
Benzouye a écrit:
Jeffbzh3 a écrit:
C'est la logique de la base de données qu'on ne comprend pas.
Comment crée une base de données à partie de rien
Je vous conseille la lecture du doc "Conception BDD" dans ma signature ... et l'utilisation d'un logiciel de modélisation MCD avant de faire vos tables, cela vous oblige à bien réfléchir à vos entités, leurs relations et leurs cardinalités ... Partir directement dans MySQL WorkBench c'est souvent passer à côté de choses importantes (à moins d'avoir un peu de bouteille dans la modélisation).
Jeffbzh3 a écrit:
il y a toujours eu les ingrédients, ils sont les suppléments et les composants, car le restaurateur pourra ajouter des sandwichs par la suite
Dans tous les modèles présentés avant il n'était jamais mention d'ingrédients ... Et cela complique un peu le modèle, puisque l'on parle alors de recettes ... Plusieurs ingrédients dans des quantités variables pour faire un produit (article) ...
Je tiens a te remercier pour ton aide Benzouye, très sympas de ta part !
Table de jointure
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
N'oubliez pas d'activer les erreurs PDO.
N'oubliez pas d'activer les erreurs PDO.
N'oubliez pas d'activer les erreurs PDO.
N'oubliez pas d'activer les erreurs PDO.
N'oubliez pas d'activer les erreurs PDO.
N'oubliez pas d'activer les erreurs PDO.