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.

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 :agenouille:

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 :)

Voici un essai de conceptualisation de tes règles de gestion : [url=http://aoutmoumane.free.fr/formation/docs/MCD_visionage.doc]MCD[/url]

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 :)

[quote]- 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...)[/quote]

N'hésitez surtout pas a signalé les erreurs que vous constatez, sa m'aidera certainement a m'améliorer :) (en tout qu'a j'espere)

Merci d'avance :)

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 :

[b]membre ______(achète)____ catégorie
méthode d'achat __|[/b]

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"

Bon aprés tout sa j'ai essayé de faire un mcd, je met l'image:
[img]http://i75.servimg.com/u/f75/11/95/75/83/testmc10.png[/img]

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 :)

[quote]Ce n'est pas parce qu'il n'y a pas d'interventions que le sujet n'est pas attractif. Mais, mine de rien, il y a des gens qui suivent en silence car ils écoutent ce que vous dites d'autant plus que ce que te propose furiouslol est juste. [/quote]

Je suis tout a fait d'accord :) et je comprend tout a fait que tout le monde ne réponde pas, mais certain continue a suivre un sujet qui les intéresses :)

Comme tu la bien fait remarqué furiouslol a bien expliqué des solutions a la problématique, et je te remercie de ta contribution également :)

Merci [b]sadeq[/b] :)

C'est vrai rif15 que les prévisions de fréquentation de ta base de donnée sont assez importantes, et donc le format de chaque champs doit etre soigneusement étudié, l'efficacité de ta base en dépend a terme

Ensuite pour revenir au options d'archivage, pour ta table VIDEOCAT décrivant qui a regardé quoi et quel jour, il te faut définir quels besoins cette table doit remplir dans le temps. Pour ton traitement de savoir si un user peut regarder une vidéo gratuitement ou non tu n'as besoin que des enregistrement du jour, par contre, vu que tu traite des données clientes, tu es un peu obligé de garder un historique des visionnages pour diverses raisons auquelles tu dois réfléchir.

J'ai eu une fois a faire a un archivage de donnée, celui ci etait effectué par un cron sous unix, qui lancait un script tous les jours a telle heure, s'occupant de delester la table en question et d'en remplir une autre, pour des besoins statistiques, c'est une solution.

Bonjour,
Ce n'est pas parce qu'il n'y a pas d'interventions que le sujet n'est pas attractif. Mais, mine de rien, il y a des gens qui suivent en silence car ils écoutent ce que vous dites d'autant plus que ce que te propose [b]furiouslol[/b] est juste.

La question du poids d'une table dans une base de données est crucial non seulement pour les traitements appliqués à cette table mais aussi pour sa maintenance : backup, import/export , ... surtout pour MySQL.

L'optimisation du volume est une question mathématique à laquelle la méthode conceptuelle relationnelle apporte quelques solutions surtout au niveau de la structure et du formatage des données à enregistrer dans une table.

Voici un exemple simple:
Si on doit conserver les données d'identité des membres, il faut une table "membre" dont les champs représentent l'ensemble des données à collecter sur un membre.
Ex minimaliste: Membre (id, nom, prenom, email)
Le volume de données de cette table dépend considérablement des types et de la taille binaire (octet) de ses champs.
Donc, si le format est le suivant :
[code]Membre (id int, nom varchar(15), prenom varchar(15), email varchar(50)) [/code]
La longueur d'un enregistrement en octet =
[list] id (4 oct)
+ nom (15 oct)
+ prenom (15 oct)
+ email (50 oct)
------------------------
= 84 oct.[/list]
Le volume de cette table pour une charge de 10 000 enregistrements = 84 oct x 10 000 = 821 Ko

Avec cette formule de calcul, on constate que si le nombre de champs change(augmente ou diminue), le volume change (augmente ou diminue respectivement) alors systématiquement pour un même nombre d'enregistrements.
De même, si les formats (type/taille) de données changent, le volume change aussi pour un même nombre d'enregistrements.
Et finalement le volume peut changer aussi si le nombre d'enregistrements change.

On comprend par ça que le volume en octets dépend fortement de 3 événements : le nombre de champs, le format de données choisi pour les champs et le nombre d'enregistrements stockés dans la table.
La question de l'optimisation du volume doit être projetée donc sur ces trois axes.

Mais on peut remarquer que les deux axes concernant les champs (nombre et format) ont un caractère prépondérant par rapport à l'axe concernant le nombre d'enregistrements. Car il faut bien fixer la structure de la table avant de la mettre en service pour accueillir les données.
C'est pour cela que l'optimisation de la structure ou format des données est une question qu'il faut aborder au niveau de la structuration et la création de la base de données et non à postériori.

Par contre, l'optimisation au niveau du nombre d'enregistrements d'une table peut avoir des solutions relevant de l'administration de données comme l'archivage et l'épuration, le découpage logique et le clusturing ...

En ce qui te concerne, je te conseille, puisque tu es en train de restructurer ta base, de bien réfléchir sur le découpage des structures de tes tables, la distribution des champs et leur formatage (type/taille) sans rentrer en conflit avec le format et le contenu des données existantes.

Le découpage et la mise en relation des tables engendre un dédoublement de données liées ; pour ne pas affecter trop le volume global de la base il est conseillé d'utiliser des index numériques (clés primaires, clés étrangères, index de regroupement et index de contrainte d'unicité) comme liens entre les tables (selon le modèle relationnel)
Le choix du format du champ (type/taille) jouant le rôle d'index est important car un index engendre un dédoublement des enregistrements concernant ce champ. C'est pour cela qu'un format numérique (le plus petit possible => entier) est souvent recommandé.

En ce qui concerne les limites d'une base de données MySQL, je pense que c'est une question qui est relative à la configuration de l'environnement dans lequel MySQL tourne (les outils déployés pour l'administrer, le client qui l'interroge par des requêtes, etc...)

Par exemple, Si c'est un environnement Web utilisant PHP, le premier événement qui risque de perturber et le timeout Web qui pourrait ne pas convenir avec le temps d'attente de la réponse du serveur de données suite à une requête sur une table trop lourde ou à une requête complexe (trop de champs, de relations...)
Deuxième exemple, si on utilise Un utilitaire Web pour administrer MySQL comme PHPMyAdmin, le premier événement qui perturbe est la configuration du débit autorisé pour le postage ou l'upload de données lors d'import/export ou de chargement de script SQL.
Le troisième exemple concerne le problème relatif aux données de type texte : l'encodage des caractères et les délimiteurs et le problème des caractères binaires comme le contenu d'une image incorporée.

Ouais je pensais que ca allait réagir la dessus :) Je t'ai exposé les bases a mon sens, le tout etant d'essayer d'éviter la redondance d'information, par contre en terme de limite d'utilisation j'aurias aimé avoir aussi un avis

Merci a toi furiouslol pour toute ton aide, par contre mon sujet n'a pas l'air spécialement attractif pour d'autre avis/explication :s
Je vais essayé d'apprendre la logique de conception d'une bdd, sa m'aidera surement, malgré qu'au premier abord sa ne semble pas spécialement simple.

Si d'autre lecteurs on des avis par rapport aux questions ci-dessus, n'hesitez pas a laissé votre analyse/idée, je prend tout :)

Encore merci a toi furiouslol :)

Oué c'est la question a se poser, c'est la seule table qui va gonfler, cependant elle sera capable de le faire car d'une structure tres simple, les deux id qui la compose etant des entiers.

On a donc une table d'une structure tres réduite, qui risque de prendre du poid néanmoins assez rapidement si tu as du gros traffic, la on peut causer réellement d'optimisation, je ne pense pas que le COUNT pose beaucoup de probleme mais je connais mal les limites mysql pour te répondre, aussi je vais laisser la parole aux anciens qui m'ont laissé causer jusque la :)

Alors la question est :

Y a t'il un autre conceptuel plus adapté a une table qui recoit beaucoup d'update, et sinon quels systemes mettre en place pour maitriser la taille de cette table ?

Merci beaucoup de toutes tes explications et du temp que tu me consacre.
Je vais regarder avec beaucoup d'interet ta solution.

J'ai déja une question quand meme par rapport a la table visionnage.
Si je propose a chaque visiteur 5 vidéos gratuite par jour, sa fait 5 entré par visiteur, donc en partant du principe que sa va marcher (il faut quand meme etre optimiste), et en imaginons (ce que j'espere bien sur, pas au début ces sur mais bon) qu'il y est 10 000 visiteurs par jour (ce chiffres est en dessous des concurrents identifié), sa fait 50 000 entrés dans la table. les traitement dessus, le comptage a proprement parler d'entré pour un membre se fera t'il facilement, ou le traitement sera compliqué?

Je te remercie en tout qu'a pour toute ton aide :)

Non non :)
c'est justement la le soucis dnas ta compréhension du systeme de donnée, si tu créé une table catégorie, elle doit etre de cette forme la :

[code]CATEGORIE
id_catégorie (clé primaire autoà incrémentable pâr exemple)
nom (de la catégorie)[/code]

Ca suffit amplement pour la table catégorie, pas d'id membre dans cette table, d'ailelurs c'est une table de catégorie de vidéo.

Ta table video:

[code]VIDEO
id_video (clé primaire autoà incrémentable pâr exemple)
nom (titre) de la video)
ici tu rajoute les renseignements propres a ta vidéo, exemple le réalisateur, la durée etc ... pas d'id_membre !![/code]

Ensuite il te faut te poser la question suivante: une video peut elle appartenir a une ou a plusieurs catégorie ? Si chaque vidéo appartient a une et une seule catégorie de vidéo, alors tu peux rajouter un champ id_catégorie dans ta table VIDEO
Sinon il te faut une troisieme table qui stockera ls relations entre vidéo et catégorie :

[code]VIDEOCAT
id_video
id_categorie[/code]

Il te reste a traiter la relation entre tes membres et tes videos. Chacun de tes membres va visionner une ou plusieurs videos (voire meme aucune). Pas de soucis, tu créé une table relationnelle pour stocker ca

[code]VISIONNAGE
id_membre
id_video
date_visio [/code]

En stockant ca, tu sais exactement qui a regardé quoi et a quel moment, tu peux donc facilement savoir qui a visonné combien de vidéo a quelle date, ce qui est déja pas mal pour ton probleme

Il te reste plus qu'a distinguer les visonnages payant de ceux qui sont gratuits. Pour ca il te suffit de rajouter un champ "gratos" dans ta table VISONNAGE, qui contiendra 0 ou 1 selon les cas. Ta table devient donc
[code]VISIONNAGE
id_membre
id_video
date_visio
gratos (exemple 0 pour gratuite et 1 pour payante)[/code]

Ainsi pour savoir si untel a atteind son quota de vidéos gratuite pour la journée, une petite requete suffira :

[code]SELECT COUNT(*) FROM VISIONNAGE WHERE id_membre="id de untel" AND date_visio=NOW() AND gratos=0;[/code]Si le résultat de cette requete est 5, alors le type n'a plus de credit gratos pour la journée, tu lui refuse le visionnage gratos, sinon c'est ok il peut regarder gratos

Voila de cette facon tu as des tables efficaces, qui ne gonfleront pas exessivement. La seule table qui gonflera avec le temps sera la table VISONNAGE, puisqu'elle prendra une ligne a chaque fois qu'un membre regardera une vidéo, mais on est loin de ta table PARAM_VISION tout de meme ...
Apres je ne sais pas quel est ton niveau en SQL, car il va falloir faire des requetes pour pouvoir lire tout ca et l'utiliser dans ton application, mais tu me demandes comment optimiser, je te répond "fait comme ca, ca te formera et tu verras ca te plaira" :)

PS: a ce sujet y a un tres bon tuto sur les JOINTURE sur ce forum si jamais t'as besoin

Re-bonjour,
Merci de tes infos :)
Je vais me penché sur la structure a adopté.

J'avais également pensé a faire une table par catégorie, et a chaque enregistrement d'un membre, il s'enregistre en meme temp dans les catégorie.
Mais du coup si il y a 10 000 membres, il y a également 10 000 enregistrement dans chaque table catégorie.

Si d'autre personne on également des avis, surtout n'hésitez pas a les partagers :)