Si certain d'entre vous connaise et peuve commenter les erreurs, c'est mon premier alors je m'attend pas a ce que se soit parfait loin de la
, je vous en serez reconnaisant Merci d'avance
la communauté d'entraide francophone dédiée au PHP
difficulté conception base de données
C'est intéressant. Moi j'interviendrais sur la partie achat de catégorie de vidéo.
Le fait d'associer membre --(choisir)--> méthode d'achat --(payer)--> achat --(concerner)--> catégorie ne permet pas d'enregistrer directement un achat de catégorie par un membre.
Je crois que à la création d'un événement d'achat, la méthode d'achat (par carte ou chèque) est une donnée qu'on peut classer au même titre que les données concernant le membre acheteur et la catégorie achetée. Toutes ces données sont obligatoires pour établir un achat. C'est pourquoi je dirais qu'il y a une association ternaire entre "membre", "catégorie" et "méthode d'achat". Cette association est bel est bien l'événement d'achat.
Donc, le modèle devient :
membre ______(achète)____ catégorie
méthode d'achat __|
Initialement ça ce lit : un membre achète une catégorie par carte ou chèque.
Mais, globalement, Un membre achète N catégories en utilisant N méthodes d'achat (carte ou chèque) dans le temps.
L'association "achète" trace le temps par l'attribut "date achat" obligatoire.
Bien sûr, si tu suis ce raisonnement t'auras plus d'entité "achat" et donc plus de d'attribut "id_achat" car logiquement on n'a pas besoin d'identifier les achats par un id puisqu'ils sont normalement identifiés dans le temps par les acteurs prépondérants : le membre et la catégorie achetée. "achat" n'est donc pas une entité, c'est une association qui représente l'événement d'achat créé par la relation entre un membre et une catégorie en vue de l'acheter.
voilà. C'est mon point de vue.
Pour les autres parties cela dépend des règles de gestion que tu n'as pas donné. Par contre au niveau des "newsletter" le nom de l'identifiant n'est pas correct, tu aurais du le nommer "id_news" pour ne pas confondre avec les inscriptions qui, normalement, sont représentées par l'association entre "membre" et "newsletter"
Le fait d'associer membre --(choisir)--> méthode d'achat --(payer)--> achat --(concerner)--> catégorie ne permet pas d'enregistrer directement un achat de catégorie par un membre.
Je crois que à la création d'un événement d'achat, la méthode d'achat (par carte ou chèque) est une donnée qu'on peut classer au même titre que les données concernant le membre acheteur et la catégorie achetée. Toutes ces données sont obligatoires pour établir un achat. C'est pourquoi je dirais qu'il y a une association ternaire entre "membre", "catégorie" et "méthode d'achat". Cette association est bel est bien l'événement d'achat.
Donc, le modèle devient :
membre ______(achète)____ catégorie
méthode d'achat __|
Initialement ça ce lit : un membre achète une catégorie par carte ou chèque.
Mais, globalement, Un membre achète N catégories en utilisant N méthodes d'achat (carte ou chèque) dans le temps.
L'association "achète" trace le temps par l'attribut "date achat" obligatoire.
Bien sûr, si tu suis ce raisonnement t'auras plus d'entité "achat" et donc plus de d'attribut "id_achat" car logiquement on n'a pas besoin d'identifier les achats par un id puisqu'ils sont normalement identifiés dans le temps par les acteurs prépondérants : le membre et la catégorie achetée. "achat" n'est donc pas une entité, c'est une association qui représente l'événement d'achat créé par la relation entre un membre et une catégorie en vue de l'acheter.
voilà. C'est mon point de vue.
Pour les autres parties cela dépend des règles de gestion que tu n'as pas donné. Par contre au niveau des "newsletter" le nom de l'identifiant n'est pas correct, tu aurais du le nommer "id_news" pour ne pas confondre avec les inscriptions qui, normalement, sont représentées par l'association entre "membre" et "newsletter"
--------//////----//---//----//////
-------//---//----//---//----//---//
------//////----//////-----//////
-----||--------||--||---||
Prendre le recul n'est pas une perte de temps.
ps: Affrontez moi dans l'arène
-------//---//----//---//----//---//
------//////----//////-----//////
-----||--------||--||---||
Prendre le recul n'est pas une perte de temps.
ps: Affrontez moi dans l'arène
Merci de ta réponse
Effectivement pour l'achat je trouve ta méthode intéressante, et qui correspond mieux au besoin.
Concernant la newsletter, c'est vrai que le nom peut porter a confusion, mais je ne suis pas sur que ma méthode soit bonne pour ce que je cherche a faire, en faite, je veux savoir quel membre est inscrit a la newsletter, il n'y a qu'une newsletter (avant dans ma base table j'avais un champ newsletter, avec comme valeur 0 (non inscrit), ou 1 pour inscrit, mais je pense pas que se soit une bonne méthode (?))
Sinon, c'est vrai que sans les contraintes, ses difficilement exploitable, je vous mets donc la liste que je me suis faite avant de commencer le mcd, peut etre que les erreurs apparaitront encore plus nombreuse
(en tout qu'a j'espere)
Merci d'avance
Effectivement pour l'achat je trouve ta méthode intéressante
, et qui correspond mieux au besoin.Concernant la newsletter, c'est vrai que le nom peut porter a confusion, mais je ne suis pas sur que ma méthode soit bonne pour ce que je cherche a faire, en faite, je veux savoir quel membre est inscrit a la newsletter, il n'y a qu'une newsletter (avant dans ma base table j'avais un champ newsletter, avec comme valeur 0 (non inscrit), ou 1 pour inscrit, mais je pense pas que se soit une bonne méthode (?))
Sinon, c'est vrai que sans les contraintes, ses difficilement exploitable, je vous mets donc la liste que je me suis faite avant de commencer le mcd, peut etre que les erreurs apparaitront encore plus nombreuse
N'hésitez surtout pas a signalé les erreurs que vous constatez, sa m'aidera certainement a m'améliorer- 1 visiteur peut s'incrire au site est devenir un membre
- 1 membre peut s'inscrire/se désinscrire a une newsletter et partager ou pas ces informations
- 1 membre fournit des informations marketing (préference de consommation...) pour un ciblage pub (beaucoup de critére a prévoir)
- 1 membre peut recevoir un message privé
- 1 membre a accés a différente catégorie gratuite
- 1 membre peut regarder 5 video par jour de chaque catégorie gratuite
- 1 membre peut acheter des visionnage supplémentaires
- 1 membre peut visionner des vidéo payante
- 1 membre accumule des points fidélité
- 1 membre peut commander des articles avec ces points
- 1 membre récolte des bonus par catégorie
- 1 membre a un meilleur score par catégorie (dans l'optique d'un futur questionnaire)
- 1 membre a un dernier score par catégorie (dans l'optique d'un futur questionnaire)
- 1 membre a une date d'inscription
- 1 membre a un nombre de connection
- 1 membre peut avoir un parrain ou des filleuls
- 1 membre a un statut vip
- 1 membre a un certain nombre de visionnage/catégorie (différent suivant la catégorie) limité par jour
- 1 catégorie a un meilleurs score établit (en vue du questionnaire)
- 1 catégorie gratuite a un nombre de visionnage limité par jour
- 1 catégorie gratuite a un nombre total de visionnage
- 1 catégorie gratuite rapporte des points fidélité
- 1 catégorie payante a un nombre de visionnage illimité
- 1 catégorie payante a un cout en point fidélité
- 1 catégorie payante débite les points du membre
- 1 catégorie payante peut etre visionné si le membre a le nombre de point nécéssaire
- 1 catégorie payante rapporte des points fidélité
- 1 visionnage a une date
- 1 visionnage a un score (avec le formulaire)
- 1 visionnage rajoute des point fidélité
- 1 visionnage est fait par un membre
- 1 visionnage est fait dans une catégorie
- 1 visionnage est sauvegardé
- 1 commande est lié a un membre
- 1 comande a un statut
- 1 commande a une date
- 1 commande concerne 1 article
- 1 commande est sauvegardé
- 1 article a 1 cout en point fidélité
- 1 article a 1 désignation
- 1 article a une description
- 1 article a un stock
- 1 article a un stock mini d'alerte
- 1 achat de visionnage est enregistrer
- 1 achat de visionnage a un mode de payement
- 1 achat de visionnage a un code
- 1 achat de visionnage a une date
- 1 historique garde les opérations effectué (visionnage gratuit/payant, commande...)
(en tout qu'a j'espere)Merci d'avance
Voici un essai de conceptualisation de tes règles de gestion : MCD
--------//////----//---//----//////
-------//---//----//---//----//---//
------//////----//////-----//////
-----||--------||--||---||
Prendre le recul n'est pas une perte de temps.
ps: Affrontez moi dans l'arène
-------//---//----//---//----//---//
------//////----//////-----//////
-----||--------||--||---||
Prendre le recul n'est pas une perte de temps.
ps: Affrontez moi dans l'arène
Je te remercie beaucoup de ton implication et de ton aide, je vais consulter tout sa trés vite
Vraiment merci pour le temp que tu as dut passer a analysé mon projet
J'ai regarder ton document, vraiment trés interessant, tu as bien cerner ma problématique.
Quelque petite question tout de meme, pour la newsletter, tu mets un champ "newsletter" dans la table "membre" du type oui/non c'est bien cela (idem pour le nombre de connection, avec une valeur par contre)?
Concernant les scores pour le futurs questionnaires, je n'ai pas trop comprit ou tu conseillez de les stocké, et du coup ou les retrouvés :s
En tout qu'a je te remercie de ton implication pour m'aider
Vraiment merci pour le temp que tu as dut passer a analysé mon projet
J'ai regarder ton document, vraiment trés interessant, tu as bien cerner ma problématique.
Quelque petite question tout de meme, pour la newsletter, tu mets un champ "newsletter" dans la table "membre" du type oui/non c'est bien cela (idem pour le nombre de connection, avec une valeur par contre)?
Concernant les scores pour le futurs questionnaires, je n'ai pas trop comprit ou tu conseillez de les stocké, et du coup ou les retrouvés :s
En tout qu'a je te remercie de ton implication pour m'aider
puisque tu n'as qu'une seule newsletter vaut mieux stocker l'adhésion OUI/NON dans la table membre. Pour les questionnaires, après réflexion, je n'ai pas tout compris de comment ils vont marcher ou du moins comment toi tu veux qu'ils fonctionnent.
--------//////----//---//----//////
-------//---//----//---//----//---//
------//////----//////-----//////
-----||--------||--||---||
Prendre le recul n'est pas une perte de temps.
ps: Affrontez moi dans l'arène
-------//---//----//---//----//---//
------//////----//////-----//////
-----||--------||--||---||
Prendre le recul n'est pas une perte de temps.
ps: Affrontez moi dans l'arène