Architecture base de données.

Résolu/Fermé
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 - Modifié par Creutzou le 20/07/2011 à 16:37
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 - 22 juil. 2011 à 13:01
Bonjour,

j'ai comme projet de faire un petit site php en utilisant le design pattern MVC.

Seulement je pêche un peu dans la construction de ma base de données.
Je voulais avoir votre avis.

(je plante rapido le décors)

Prenons le domaines de la vente aux enchères.
Nous avons des commissaires priseurs, qui peuvent mettre en ligne, 0 à n ventes.
et nous avons des ventes qui peuvent contenir 1 à n objets.

Je pensais donc faire un petit quelque chose comme ça:

etude(id,nom,adresse,mail.....)
vente(id,id_etude,titre,description,date....)
item(id,id_vente,titre,description,photo....)


Que pensez vous de mon modèle ?

Je suis preneur de toute critique !


En vous remerciant grandement d'avance.

ps: le modèle me parait bien, seulement pour la structure derrière, ( les contrôleurs surtout) je ne vois pas trop comment faire.

ps2: Que pensez vous de tout mettre dans la même table? ou grouper la table vente/item ? je suis un peu perdu et je ne sais quoi faire .

Je ne suis pas un geek, juste un humain 2.0
~~ Cr3u7z0u ~~

4 réponses

a.laumiere Messages postés 18 Date d'inscription mardi 7 juin 2011 Statut Membre Dernière intervention 16 septembre 2011 3
20 juil. 2011 à 20:14
Bonjour,

Vu le contexte, j'opterais pour l'ajout d'une table intermédiaire:
etude(id,nom,adresse,mail.....)
vente(id,id_etude,titre,description,date....)
vente_item(id_vente,id_item)
item(id,titre,description,photo....)

Peut-être très utile dans le cas où un item n'est pas vendu lors de la première vente et est proposé sur une autre vente, tout cela en gardant la possibilité de voir facilement l'historique des ventes d'un item.

A voir en fonction des besoins métiers...
1
HostOfSeraphim Messages postés 6750 Date d'inscription jeudi 2 février 2006 Statut Contributeur Dernière intervention 31 juillet 2016 1 608
21 juil. 2011 à 13:21
La double clé primaire dans vente_item sous-entend qu'un objet puisse être vendu dans plusieurs ventes... est-ce le cas ?

J'aurais plutôt fait :

etude(id,nom,adresse,mail.....)
vente(id,titre,description,date.... id_etude)
item(id,titre,description,photo.... id_vente)
0
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 30
Modifié par Creutzou le 21/07/2011 à 13:29
( a prendre avec des pincettes) En gros je pensais faire, une grande table contenant tous les objets avec un statut ( en stock, en vente, vendu ou je ne sais pas trop quoi d'autre).

lorsque que l'on créer une vente, on " place" des objets dans cette vente.

Un objet A ne peut être présent que dans UNE et UNE seule vente à la fois. Il peut en faire plusieurs à la suite, mais pas simultanément.

je ne sais pas si je me fais bien comprendre, c'est déjà un peu embrouiller dans mon esprit. Donc c'est pas facile à expliquer. Désoler.
0
HostOfSeraphim Messages postés 6750 Date d'inscription jeudi 2 février 2006 Statut Contributeur Dernière intervention 31 juillet 2016 1 608
21 juil. 2011 à 13:34
Si l'objet peut faire plusieurs ventes successives, il vaut mieux alors garder l'option de la table intermédiaire : elle permettra d'avoir un historique des ventes où l'objet a été proposé.
0
a.laumiere Messages postés 18 Date d'inscription mardi 7 juin 2011 Statut Membre Dernière intervention 16 septembre 2011 3
21 juil. 2011 à 14:29
Pour chaque notion, il faut se poser la question des relations dans les 2 sens, c'est à dire :
- une vente contient 0-n item, un item apparaît dans 0-n vente
- un statut a 0-n item, un item a ... statut

Pour la relation item-statut, ce n'est que mon avis mais je pense que le statut d'un item est aussi lié à la vente, un item peut-être au statut "en stock" sur la première vente et "vendu" sur la seconde vente ... dans ce cas cela se traduirait par un id_statut dans le table intermédiaire.

Le mieux est de se poser un maximum de questions avant pour sortir toutes ces règles ... après le modèle suivra.
0
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 30
21 juil. 2011 à 09:06
Je n'avais pas pensé à la table intermédiaire. C'est vrai que cela résoudrait quelque problème que je n'avais pas encore rencontré.

je te remercie, je laisse le thread ouvert , si jamais d'autre contraintes insolvable me viennent.
0
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 30
21 juil. 2011 à 14:58
Compte tenue de vos remarques, j'ai établis un nouveau modèle.

Etude ( id , nom_etude.... )

Statut ( id , libel ) 

Vente ( id , id_etude , id_statut , titre ... )

Item ( id, id_vente , id_statutVente , id_statutItem  ... ) 

Vente_item (  id_vente , id_item , id_statut)



Puis nous avons donc :

une Etude a 0 ou N Vente.
Une Vente est a 1 et 1 seule Etude.

Une Vente a 0 ou N Item.
Un Item est dans 0 ou N vente.

Un Item a 1 ou N statut.
Un statut a 0 ou N Item .

Je commence à y voir un petit peu plus clair.
0
a.laumiere Messages postés 18 Date d'inscription mardi 7 juin 2011 Statut Membre Dernière intervention 16 septembre 2011 3
21 juil. 2011 à 18:12
Là c'est moi qui n'y vois plus clair.
Pourquoi tout ces id_statut ?
0
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 30
22 juil. 2011 à 08:26
heu , je me suis dis qu'un objet pouvait avoir plusieurs statut . Mais qu'une vente aussi.
Après réflexion, c'est complétement nouille de l'avoir mis aussi dans la table vente_item.
On peut le retrouver facilement.
0
a.laumiere Messages postés 18 Date d'inscription mardi 7 juin 2011 Statut Membre Dernière intervention 16 septembre 2011 3
22 juil. 2011 à 10:12
ok. l'id_statut de la table vente est donc justifié.
Par contre, pour moi, le statut dans la table vente_item me gène moins que les statuts dans la table item.
Si on souhaite connaître le statut "final" d'un item, alors le statut dans la table item suffit, par contre pour avoir un historique des statuts (phrase: un item peut-être au statut "en stock" sur la première vente et "vendu" sur la seconde vente), le statut dans vente_item est nécessaire.
0
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 30
22 juil. 2011 à 10:31
je pensais effectivement avoir un historique des statut pour un item. Et connaitre le statut "du moment" de ce même item. Mais c'est vrai qu'en rajoutant une date ou en jouant avec les id on pourrait trouver son dernier statut.
Je ne pensais pas ça, si compliquer au début ^^
0
a.laumiere Messages postés 18 Date d'inscription mardi 7 juin 2011 Statut Membre Dernière intervention 16 septembre 2011 3
22 juil. 2011 à 10:48
oui, c'est pour ça qu'il faut lister tout les besoins dès le départ.
Si tu te rends compte à posteriori que, par exemple, tu peux avoir une vente réalisée sur 2 jours avec 2 commissaires priseurs différents ... tu devra revoir ton modèle et ça te prendra plus de temps que si tout est correct au départ.
0
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 30
22 juil. 2011 à 13:01
Merci, je vais jeter un coup d'oeil a ça, et j'ouvrirais un nouveau thread en cas de besoin.
J'ai déjà pas mal avancé !

Merci beaucoup.
0