-
Edité par LzM_nice 21 septembre 2017 à 14:10:50

Bonjour,

Un particulier et un distributeur ne sont pas si différents ... ce sont deux clients ... chacun avec des particularités ... Dans ce contexte, on parle d'héritage. Une entité mère (client) qui donne naissance à deux entités fille (particulier et distributeur).

Un peu de lecture sur l'héritage

Le modèle conceptuel serait :

Dans ce cas, c'est toujours un client qui passe commande. Le fait qu'il ait une référence dans l'une ou l'autre des entités fille te permet de déterminer ce qu'il est plus particulièrement ...

Après c'est à ton application d'appliquer des règles de gestion différentes selon l'entité fille ...

Bonjour et merci pour ta réponse

juste une dernière petite question, tu as mis un id auto_increment pour l'USINE, 

cependant, il n'y aura qu'1 seul usine, jamais plus.

est ce que c'est utile de laisser cet auto increment ?

LzM_nice a écrit:

il n'y aura qu'1 seul usine, jamais plus.

Dans ce cas, l'entité usine n'a peut-être pas de sens ... tu pourrais carrément la supprimer ...

Après ce peut être intéressant de la conserver dans une optique d'évolution "multi-site" de production ... à voir si cela a du sens pour toi.

ok, merci pour tes conseils

après reflexion, je vais supprimer l'USINE.

Autre question 

je veux faire un site internet, avec un login;

• les DISTRIBUTEURS pourrons consulter et ajouter des références produits a la BDD
• les PARTICULIERS ne pourrons que la consulter
• l'admin fera ce qu'il voudra

il me semble que ce n'est que des privilèges différents accordé a chacun

cependant

est ce que je dois créer la table LOGIN et les relations entre les tables produits, particuliers, distri..... a l'intérieur de cette BDD

ou bien faire une BDD différentes qui décidera des droits d'accés sur cette BDD ci.

Désolé pour te poser une question aussi simple, mais je m'éparpille trop dans mes recherches.... je suis débutant avancé, et j'hesite beaucoup.

Pas de table login à créer, la table client suffit. Il faut juste y rajouter une colonne identifiant et une colonne mot de passe qui permettront de valider la connexion à l'application.

Par contre si un client (plutôt un distributeur d'ailleurs) peut avoir plusieurs utilisateurs, c'est une nouvelle entité avec une relation vers client ...

Ensuite pour la question des droits ... Il n'y a pas de réponse directe ... Le plus simple c'est de faire porter les règles de gestion par l'application.

Lorsque l'utilisateur se connecte, tu demande à la BDD si les identifiants sont bons, et si oui, quel est le type du client, particulier ou distributeur.

Une fois cela déterminé tu affiches les éléments en fonctions (bouton "modifier" par exemple) et à chaque action tu vérifies si l'utilisateur a bien les droits pour l'exécuter ...

Une autre façon est de stocker les droits en base de donnée. Cela implique la création de tout une mécanique utilisateurs/profils/droits. Tu crées des profils d'utilisateur, et les affecte à chacun des utilisateurs. Tu stockes dans la table droits toutes les actions possibles dans ton application que tu relis à chaque profil en précisant si oui ou non le droit est accordé à ce profil. C'est un peu plus complexe et fastidieux, mais cela te permet de pouvoir faire évoluer plus simplement les droits sans retoucher ton code applicatif ... maintenabilité / évolutivité ...

ok, merci.

je souhaite maintenant m'attaquer au login, pour créer des sessions 

ma question est:

pour "definir" la personne qui s'inscrit/se connecte, je dois utiliser les infos de la table UTILISATEUR et non pas celle de CLIENT (puisque chaque client est également un utilisateur)

autrement dit, je vais UNIQUEMNT enregistrer/modifier:

id_utilisateur ; identifiant_utilisateur, motdepasse_utilisateur

ou bien, je dois y ajouter les : id_client, adresse, codepostale, ville, de la table CLIENT

je pense que c'est la 1er réponse, non

Vu qu'un utilisateur est lié à un client et un seul, alors par le jeu des jointures tu retrouveras les données d'adresse du client selon l'utilisateur connecté ...

Après si tu veux distinguer les coordonnées de l'utilisateur de celle du client, alors oui il faudra augmenter la table utilisateur de ces données ...

ok, d'accord.

par contre, j'ai un petit doute; les :

id_client  et id_utilisateur, sont tout les 2 auto_incrementés; cela ne vas t il pas poser probleme?

ou bien , c'est comme ta réponse précédente, 1 utilisateur = 1client

Dans le dernier modèle proposé, un client peut avoir plusieurs utilisateurs distincts, du coup il est normal d'avoir une entité "utilisateur" à part avec sa propre clé primaire. Elle sera relié à l'entité "client" par une clé étrangère id_client dans la table utilisateur.

Si un client n'a qu'un seul et unique utilisateur, alors reste sur le précédent modèle proposé, en rajoutant simplement des attributs identifiant et mot de passe dans l'entité client.

donc si je comprends bien....

je souhaite avoir 1 seul contact (1 seul id ) par client (1 seul contact/id chez le client DISTRIBUTEUR ), donc, je n'ai plus besoin de la table UTILISATEUR

je mets tout les usurnam, password.. directement dans CLIENT

mon MCD deviens relativement simple.... je cherchais quelque chose de trop compliqué.... merci beaucoup pour ta patience et ton aide.