Architecture base de données.
Résolu
Creutzou
Messages postés
550
Date d'inscription
Statut
Membre
Dernière intervention
-
Creutzou Messages postés 550 Date d'inscription Statut Membre Dernière intervention -
Creutzou Messages postés 550 Date d'inscription Statut Membre Dernière intervention -
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 ~~
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 ~~
A voir également:
- Architecture base de données.
- Fuite données maif - Guide
- Logiciel architecture gratuit - Télécharger - Architecture & Déco
- Base de registre - Guide
- Supprimer les données de navigation - Guide
- Tnt base de données vide - Forum TNT / Satellite / Réception
4 réponses
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...
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...
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.
je te remercie, je laisse le thread ouvert , si jamais d'autre contraintes insolvable me viennent.
Compte tenue de vos remarques, j'ai établis un nouveau modèle.
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.
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.
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.
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.
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.
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.
J'aurais plutôt fait :
etude(id,nom,adresse,mail.....)
vente(id,titre,description,date.... id_etude)
item(id,titre,description,photo.... id_vente)
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.
- 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.