Bonjour,

j'ai réalisé un petit projet avec Vuejs. J'ai fait la partie front-end, et je dois à présent réaliser la partie back-end.

Il s'agit d'une appli pour commander de la nourriture. Pour l'instant les données (les plats etc) sont dans un json sous la forme d'objets dont je me sers dans Vuejs. Je sais que mon objectif est que le json soit à terme généré par le php. Je commence à apprendre php ainsi que mySQL. J'ai réalisé des schémas de mes tables sur sqldb et mocodo online. Pour avancer, que devrai-je faire ensuite à mon niveau ?

Puis-je créer les tables maintenant ? Dois-je travailler avec Workbench, ou bien Wamp (déjà installé) suffit-il pour travailler ?

Je note que j'ai l'ambition d'utiliser Stripe pour générer un message (valide ou invalide)  en simulation d'achat sans effectuer de paiement réel.

Avez-vous des conseils avant de commencer à ce stade-là ? Sur quoi devrai-je me concentrer en premier ? Y a t-il des premières précautions à prendre ?

En php je m'entraine à faire des petits projets séparés, dois-je commencer un script "orienté" vers mon projet maintenant pour gagner du temps ?

Je poste également quelques modèles de tables dont je pense me servir.

Bonne journée

-
Edité par ElieL. 23 juin 2021 à 16:22:50

Bonjour,

C'est étrange de commencer par le front-end ...

Un projet commence normalement par l'analyse fonctionnelle (cahier des charges) dont découle la modélisation conceptuelle des données (MCD) dont découlent le modèle logique (MLD) et le modèle physique (MPD). Une fois cela mis en place on conçoit les fonctions CRUD (Create, Read, Update, Delete), que l'on peut pourquoi pas regrouper dans une API type REST (en PHP ou autre langage serveur). Enfin on conçoit le front-end (l'interface utilisateur) qui s'appuie sur ces fonctions ... Il peut être utile de faire une maquette de l'interface (mock-up) en amont de la conception, mais sans aller dans l'utilisation d'un framework, on fait du visuel pas du fonctionnel ...

Mais passons, c'est fait maintenant ...

Tout d'abord, je te conseille d'utiliser l'excellent Looping pour concevoir ton MCD/MLD/MPD, bien plus souple et complet que MoCoDo, et aussi libre et gratuit.

Une fois le MCD validé, Looping te génère le SQL associé, que tu peux directement importer dans MySQL (via PHPMyAdmin par exemple).

Je te déconseille MySQL WorkBench qui te prive de la vraie réflexion autour du MCD et t'oblige à faire du MPD directement.

Concernant ton MCD actuel je pense qu'il faut revoir la notion de cardinalité ...

En l'état un plat est dans plusieurs catégories et une catégorie contient plusieurs plats. C'est une relation n,n qui donne une table de relation RASSEMBLE. Cela me paraît étrange dans ton contexte, non ?

La relation CONTIENT a des cardinalités 0,0 --- 3,3 je pense que c'est aussi à repenser ...

Enfin, sans en savoir plus sur ton projet et les fonctionnalités attendues, il est difficile de critiquer le MCD que tu proposes.

Merci beaucoup pour cette réponse, 

la relation CONTIENT a des cardinalités en 0,3 pour illustrer le fait que chaque menu contient 3 plats. Est-ce mal rédigé ainsi ?

Je vais essayer de donner plus de détails sur le projet, dès que possible. J'ai fait un cahier des charges initial, mais je pense que je dois sélectionner les infos à partager pour ne pas polluer le forum et aussi conserver de la discrétion. Y a t-il des infos que je dois partager en particulier ? Expression des besoins, etc ? Peut-être dois-je faire un petite démo du front end existant, ce serait plus clair ? Voire partager le json actuel ?

Bonne journée

ElieL. a écrit:

la relation CONTIENT a des cardinalités en 0,3

Pas vraiment ... tu as 0,0 --- 0,3. Si un plat peut-être présent dans plusieurs menus (plusieurs ou un nombre connu ?), et qu'un menu contient 3 plats, les cardinalités seront :

• plat 0,n --- 0,3 menus

Attention la cardinalité 3 ne sera pas gérable directement dans le MLD, il faudra rajouter un mécanisme de contrôle dans le MPD pour assurer cette contrainte, avec un TRIGGER BEFORE INSERT par exemple.

J'ai mis 0,3 du côté des menus car dans l'absolu on ne peut créer directement un menu avec 3 plats. Il faudra d'abord créer le menu pour avoir son id. Dès lors il existe mais sans plat (0), et on ajoute les plats ensuite.

ElieL. a écrit:

Peut-être dois-je faire un petite démo du front end existant, ce serait plus clair ?

Simplement expliquer comment doit fonctionner l'appli, ce que peut faire l'utilisateur, ce que tu attends en retour (indicateurs, calculs, affichage).

Merci, je prends note, je ne connais pas encore TRIGGER BEFORE INSERT.
Pour l'instant, de mémoire, les plats sont tous différents, ils ne sont pas présents dans plusieurs menus. J'ai pour l'instant 3 menus de 3 plats. J'utilise des images libres de Unsplash pour l'affichage.

Je vais tenter de reprendre le mécanisme de fonctionnement de l'appli :

L’application nécessite une connexion internet. Le site a pour principales vocations de choisir et acheter des plats et menus. Je travaille en local (http://localhost:8080/). Voici une liste des fonctionnalités : Une page d’accueil avec un carrousel, une navigation, un panier d’achat, des pages de contact et de mentions légales, un affichage des produits par catégories à l’aide de boucles, une responsivité pour adaptation sur différents types d’écrans.

- le Menu, présent sur toutes les vue : composé d'un bouton "vers home", et bouton 3 points qui ouvre et ferme le menu de navigation.

- le footer (présent également sur toutes les autres pages du site)

- Homepage : carroussel (liste photo des menus cliquables : Un bouton flèche droite montre l’image située à droite de l’item actif.

Un bouton flèche gauche montre l’image située à gauche de l’item actif), et cartes de menus cliquables

- la navigation :

boucle sur les objets Produits définis dans le data.json : 

• Plats

• Menus

- l'affichage des produits :

comporte un bouton de retour vers la homepage ainsi qu’un bouton d’affichage du panier actuel. (nombre d’articles sélectionnés, la liste des objets et (leur prix) contenus). Dans un paragraphe <p> on trouve le Retour du total à payer.

boucle sur les menus :
au clic sur un item (photo, titre ou bouton info), le bouton mène vers les InfosDisplay avec les infos suivantes displayName, photo, description, prix, disponibilité, type, id, Provenance (selon le chemin d’accès aux détails, l’affichage est différent - pas de bouton panier sur les plats si accès par “nos menus” via la navigation - mais peut-être faudra t-il le rajouter). On accède alors aux items contenus dans le menu sélectionné.

boucle sur les plats :

Les catégories sont affichées séparément grâce au parcours des 3 tableaux stockés dans le gestionnaire d’état : PlatsFromStore, DessertsFromStore, BoissonsFromStore 

Ces catégories sont accessibles par liste déroulante horizontale, gérée en css via 3 <div> imbriquées.

De même que pour les menus, au clic sur un item (photo, titre ou bouton info), le <router-link> mène vers la view InfosDisplay.vue avec les infos suivantes via params : displayName, photo, description, prix, disponibilité, type, id, Provenance (selon le chemin d’accès aux détails, l’affichage est différent - bouton panier sur les plats si accès par “nos plats” via la navigation). Mais dans ce cas-ci, on accède aux infos du plat sélectionné.

- le bouton panier, présent sur toutes les vue :

au clic sur un item :

- push de l’item dans un tableau (SendToCart) 

- une méthode (updateCart()) envoie vers le gestionnaire d’état l’item ajouté, et le prix pour mise à jour du total.

- une fenêtre Modale (pop-in) s’affiche avec un récapitulatif de l’item ajouté - les infos relatives au dernier objet inséré dans le tableau du gestionnaire d’état (nom, et prix)., et propose la possibilité de l’effacer via un bouton delete. Le bouton delete réduit la quantité de l’article de -1. Et ferme la pop-in.

- Fenêtre Modale :
Au clic sur la croix ou sur l’overlay on ferme la fenêtre modale.

- Détails des produits :

En plus des infos nom, prix, photo on trouve une icône de disponibilité ou d'indisponibilité.

Cela est-il assez clair ?

Merci pour vos retours, j'essaie de continuer de me former aux bdd, je ne vois pas encore comment faire la jonction.

Bonne journée,

Elie

ElieL. a écrit:

de mémoire, les plats sont tous différents, ils ne sont pas présents dans plusieurs menus

Si tu es sûr de cela, alors pas besoin de relation n,n :

Il te faut vraiment valider tes cardinalités avant d'aller plus loin, pour être sûr de ton modèle de données.

Mais dans mon esprit, un menu contient 3 plats différents (une entrée, un plat et un dessert) mais le même plat peut apparaître dans plusieurs menus ... Au final menu et plat ne sont même pas liés ... Le menu est juste une aide à la commande qui donne des règles de saisie ...

ElieL. a écrit:

j'essaie de continuer de me former aux bdd

Je te conseille la lecture du doc. "Conception BDD" via ma signature

Merci pour ces réponses, mais quelque chose m'échappe :

- il est juste que un plat peut être dans plusieurs menus, et un menu peut avoir plusieurs plats,

- ce qui donne une relation n,n

- donc je dois bien avoir une table entre PLATS et MENUS, qui contient les 2 Foreign Keys id_menu et id_plat.

- ce qui est bien le cas actuellement : je reposte mon sqldbm.

- je compte appliquer le même logique entre CATEGORIES et PLATS par la suite.

Merci encore pour vos retours,

Elie

OK, mais ce n'est pas ce que tu écrivais plus tôt...

Donc il y a bien une table de relation.

Ok merci, je vais aussi enlever les lignes id_rassemble et id_contient dans les tables RASSEMBLE et CONTIENT,

d'après mes recherches ces tables n'ont pas de Primary Key. l'id (contrainte d'unicité) est le couple id_menu et id_plat lui-même -

Et id_categorie / id_plat.

Prochaine étape : renommer les champs pour formaliser tout ceci,

bonne journée

ElieL. a écrit:

ces tables n'ont pas de Primary Key

Si il y a une clé primaire, mais elle est composée sur deux colonnes, par sur une.

Exemple :

CREATE TABLE relation (
    id_plat INT UNSIGNED NOT NULL,
    id_menu INT UNSIGNED NOT NULL,
    PRIMARY KEY ( id_plat, id_menu ),
    FOREIGN KEY ( id_plat ) REFERENCES plat ( id_plat ),
    FOREIGN KEY ( id_menu ) REFERENCES menu ( id_menu )
) ENGINE=InnoDB;

Bonjour,

merci pour votre aide,

j'ai pu créer ma base de données et commencer à la remplir. Looping m'a bien aidé. J'ai créé les tables d'associations mais je n'arrive pas à m'en servir pour stipuler qu'un menu contient tel ou tel plat. Dois-je rajouter une colonne "appartient au menu n°" dans ma table des `pla` ?

J'ai pu écrire une requête pour lire le contenu de certaines entités grâce à un script en php mais c'est tout.

Bonne journée,

Elie

ElieL. a écrit:

Dois-je rajouter une colonne "appartient au menu n°" dans ma table des `pla` ?

Non, c'est le rôle de la table CONTIENT de faire cela ...

Cette table doit enregistrer les couples d'id menu/plat souhaités.

Merci !

à bientôt !