optimisation modèle

**rif15** · 22/10/2008, 01h10

Bonsoir,
Je suis en pleine réflexion pour la construction de ma base de données (table,champ...)

Je vous expose mon projet:

Mon projet doit permettre a mes visiteurs inscrit de pouvoir visualisé un nombre de vidéo restreint par jour et par catégorie, chaque visiteur a la possiblité ensuite, de s'acheter des crédits pour consulté plus de vidéo (ex: catégorie 1: 5 video par jour, un achat de crédit lui donnerait 10 vidéo supplémentaire)

Je souhaite également conservé pendant un certain temp une sauvegarde des vidéos regardé par les membres, avec le pseudo, la vidéo ainsi que l'heure.

Pour le ciblage publicitaire, je souhaite également préparé ma base afin de pouvoir segmenter les profils de mes membres.

J'ai commencer par faire une table membre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9

-Nom 
-Prenom 
-Date de naissance 
-adresse 
-code postal 
-ville 
-pays

ensuite une table compte

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
-Pseudo 
-Pass 
-nombre de visite 
-Derniére connection

Dans mon premier site que j'avais fait j'avais sa:

table générale:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-pseudo 
-pass 
-prenom 
-nom 
-adresse 
-ville 
-cp 
-pays 
-nombre de visite 
-derniére connection 
-nb_video_cat1 (par defaut 5) 
-nb_video_cat1_acheter 
-nb_video_cat2 (par defaut 5) 
-nb_video_cat2_acheter 
-nb_video_cat3 (par defaut 5) 
-nb_video_cat3_acheter 
(ainsi de suite suivant le nombre de catégorie) 
-préférence1 (choix oui/non) 
-préférence2 (choix oui/non) 
-préférence3 (choix oui/non) 
(ainsi de suite suivant le nombre de préférence)

Pour les sauvegardes j'ai créer une table pour chaque catégorie, et a chaque visionnage je faisait un enregistrement avec le pseudo, la video et l'heure.

Vous aurez donc comprit que j'avais fait au plus simple sans vraiment me posé de question :s, sa fonctionné, mais ce n'était certainement pas optimiser, de plus j'ai eu beaucoup de difficulté a transférer mes tables lorsque j'ai changé de serveur.
Le site avait une base d'environt 60 000 membres.

J'avoue etre un peu perdu afin d'optimiser tout sa :s, en plus je souhaite maintenant garer des infos sur les catégorie des vidéo(combien de visionnage a eu la catégorie...)
La je bloque sur la facon de faire pour limiter le visionnage par catégorie (sans faire tout a la suite comme auparavant, qui n'était pas je pense optimisé), puis égalemet la gestion d'achat de crédit (il me faut obligatoirement un champ a part, car les vidéos acheté sont débité uniquement si les video quotidienne ont été vu, et donc si sa se chevauche sur 2 jours, le membres retrouve 5 videos gratuites avant de piocher dans ces crédits.

J'espere que vous pourrez m'aidez car j'avoue que la je suis bien embetter :s

Merci d'avance pour votre aide

**CinePhil** · 22/10/2008, 10h02

Un peu de lecture sur la conception des bases de données me semble nécessaire...
http://sqlpro.developpez.com/cours/modelisation/merise/

**rif15** · 23/10/2008, 17h46

Merci de ta réponse CinePhil, tu confirme donc que mettre comme j'avais fait précedement, ces a dire mettre tout dans une seule table n'est pas une bonne chose?

Je n'arrive pas a imaginer une autre facon que de créer un champ (ex:"limit", par catégorie video, il peut donc il y aurait autant de champ "limitx" que de catégorie) par ligne d'enregistrement dans ma table, et de le décrementer au fur et a mesure des visionnages, et une fois a 0 l'accés et refusé.
Je ne sait pas si il y a une autre méthode, si vous avez un avis la dessus je veut bien

(dans la table principale, dans une table a part, ces pas du tout bon comme méthode

je prend tout

)

D'autre part, j'ai chercher mais par encore trouver des exemple de mcd pour un site web (partie membre...), se serait pour voir déja comment séparer mes différente info, car la je nage pour le moment, donc si vous avez un lien, ou un exemple, je vous en remercie

Bon je vais allez lire les liens que ma donné CinePhil, encore merci

Merci d'avance pour vos réponses

**CinePhil** · 23/10/2008, 19h44

Envoyé par rif15

Merci de ta réponse CinePhil, tu confirme donc que mettre comme j'avais fait précedement, ces a dire mettre tout dans une seule table n'est pas une bonne chose?

Oui.

Je n'arrive pas a imaginer une autre facon que de créer un champ (ex:"limit", par catégorie video, il peut donc il y aurait autant de champ "limitx" que de catégorie) par ligne d'enregistrement dans ma table, et de le décrementer au fur et a mesure des visionnages, et une fois a 0 l'accés et refusé.

Ne commence pas d'emblée à réfléchir en manipulation de données.
Suis la méthode Merise en écrivant les contraintes avec des phrases simples qui te permettront de dégager les entités, leurs attributs, puis les associations entre entités.

Bon je vais allez lire les liens que ma donné CinePhil,

Ben il fallait commencer par là avant de répondre !
Reviens avec un début de schéma ou une liste de contraintes.

**rif15** · 26/10/2008, 17h00

Voila, je met ci-dessous une étude un peut plus précise de mes besoins et contrainte, en esperant que ce soit cela que tu demandais CinePhil (si ce n'est pas le cas, aurait tu un exemple de contrainte

):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
- 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 champ 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...)

Je vais maintenant essayé de commencer le shéma, mais si vous voyé déja des choses qui ne vont pas n'hésitez pas

, par exemple, il ne s'agit pas d'une liste de contrainte, ou encore, sa ne sert pas a réalisé le mcd

Je vous remercie d'avance pour vos réactions

et j'espere a bientot

**rif15** · 26/10/2008, 22h41

re-bonsoir,
Voila aprés avoir travailler un peu, je vous propose mon premier mcd, il n'est pas completement terminé, mais j'espere que vous pourez me conseillez, enfin montrer les erreurs, enfin voir tout ce qui ne vas pas

Je ne m'attend pas a ce que mon essai soit trés bon, mais pour un premier, j'espere ne pas avor tout faux non plus lol

J'espere que vous pourrez me conseillez et m'aidez

Merci d'avance

**rif15** · 29/10/2008, 17h42

re-bonjour,
A priori il y a un souci au niveau de la méthode d'achat, et pour la newsletter, sa me semble pas terrible non plus...

Si quelqu'un a d'autre avis/conseils, je prend tout

**CinePhil** · 29/10/2008, 18h50

Envoyé par rif15

- 1 visiteur peut s'incrire au site est devenir un membre

Ne figure pas dans le MCD mais peut-être n'est-ce pas nécessaire.

- 1 membre peut s'inscrire/se désinscrire a une newsletter et partager ou pas ces informations

Je ne vois pas dnas le MCD la seconde partie relative au partage des informations.

- 1 membre fournit des informations marketing (préference de consommation...) pour un ciblage pub (beaucoup de champ a prévoir)
- 1 membre peut recevoir un message privé

Ok.

- 1 membre a accés a différente catégorie gratuite
- 1 membre peut regarder 5 video par jour de chaque catégorie gratuite

Il s'agit de l'association 'Visionner' ?

- 1 membre peut acheter des visionnage supplémentaires

Il faut plutôt une association ternaire entre 'membre', 'achat' et 'méthode d'achat'

- 1 membre peut visionner des vidéo payante

Le MCD ne semble pas faire de distinction entre les visionnages payants et gratuits. Ce n'est pas forcément un problème mais il faut se garder ça en mémoire. A voir.

- 1 membre accumule des points fidélité

Il s'agit de l'attribut 'gain_point' dans l'association 'visionner' ?

- 1 membre peut commander des articles avec ces points

Je suppose que c'est une méthode d'achat ?

- 1 membre récolte des bonus par catégorie

OK.

- 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

Là on est plutôt du côté des attributs que des entités et des associations.

- 1 membre peut avoir un parrain ou des filleuls

Il faut alors une association réflexive sur l'entité 'membre'.
Elle s'écrirait en français : 1 membre a pour parrain au maximum 1 autre membre et 1 membre peut ou pas parrainer d'autres membres.

- 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

Là ce sont plutôt des attributs.

- 1 catégorie gratuite rapporte des points fidélité

Idem que pour les payantes vues plus hait je suppose ?

- 1 catégorie payante a un nombre de visionnage illimité
- 1 catégorie payante a un cout en point fidélité

Attributs.

- 1 catégorie payante débite les points du membre

Ne figure pas dans le MCD.

- 1 catégorie payante peut etre visionné si le membre a le nombre de point nécéssaire

Contrainte à gérer par le logiciel qui utilise la BDD.

- 1 catégorie payante rapporte des points fidélité

Déjà dit non ?

- 1 visionnage a une date
- 1 visionnage a un score (avec le formulaire)

Attributs.
[quote]- 1 visionnage rajoute des point fidélité[/quote déjà abordé plus haut non ?

- 1 visionnage est fait par un membre
- 1 visionnage est fait dans une catégorie
- 1 visionnage est sauvegardé

Euh... ça me semble correct à première vue... (je fatigue un peu là !)

- 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é

Un peu de mélange entre attributs et associations...

...
J'arrête là pour aborder un principe général...
Tu as écrit une sorte de mini cahier des charges avec pas mal de mélange entre entités, associations, attributs, contraintes...

Les étapes essentielles pour réaliser le MCD sont :
1) A partir du cahier des charges, repérer les entités, les attributs et les associations (ces dernières généralement représentées par des verbes).
2) Commencer par dessiner les entités, puis les associations.
3) Ranger les attributs dans les entités et éventuellement dans les associations
4) Passer aux cardinalités en reformulant les exigences du cahier des charges et en se posant la question : "Combien de fois telle entité peut-elle faire cette association avec telle autre ?" Voir en exemple ma reformulation sur les parrains et les filleuls.

C'est un bon début mais il y a des choses à améliorer. Du côté de l'achat comme tu l'as pressenti mais aussi du côté des visionnages gratuits ou payants et des points.

**rif15** · 29/10/2008, 20h30

Bonsoir,
Merci de cette réponse bien compléte

1 visiteur peut s'incrire au site est devenir un membre
Ne figure pas dans le MCD mais peut-être n'est-ce pas nécessaire.

Effectivement, pour moi ces implicites, seul les visiteurs qui s'inscrive vont utiliser et echanger des données avec la bdd.

- 1 membre a accés a différente catégorie gratuite
- 1 membre peut regarder 5 video par jour de chaque catégorie gratuite
Il s'agit de l'association 'Visionner' ?

Effectivement, ces ce que j'ai voulu faire avec l'association 'Visionner'

Il faut plutôt une association ternaire entre 'membre', 'achat' et 'méthode d'achat'

On m'en a effectivement parler, je vais regarder cela de prés.

Le MCD ne semble pas faire de distinction entre les visionnages payants et gratuits. Ce n'est pas forcément un problème mais il faut se garder ça en mémoire. A voir.

La je pensais dans l'entité "catégorie" utiliser l'attribut "nb_vision_gratuit" pour mettre le nombre de visionnage gratuit disponible pour une catégorie gratuite, et si il s'agit d'une catégorie payante, mettre comme valeur 0. De meme pour l'attribut "cout_vision", qui serais a 0 pour une catégorie gratuite, ou d'une valeur définie pour un visionnage payant.

Il s'agit de l'attribut 'gain_point' dans l'association 'visionner' ?

Oui c'est cela, dans l'optique d'un traitement d'attribution de point aléatoire.

Il faut alors une association réflexive sur l'entité 'membre'.
Elle s'écrirait en français : 1 membre a pour parrain au maximum 1 autre membre et 1 membre peut ou pas parrainer d'autres membres.

Merci du conseil, je vais regarder sa

J'ai essayé comme tu me l'as indiqué plus haut de ne pas pensé au traitement des données lors de la création du mcd, j'ai essayé, et c'est vra que c'est plus simple pour poser les choses, mais une fois terminé, j'ai commencer de nouveau a chercher comment les données circuleront, et le mcd m'a donné de bonne information, mais j'ai toujours du mal a imaginer le traitement de ma contrainte de nombre de visionnage par catégorie :s, si jamais en lisant cela quelqu'un a une idée n'hésitez pas

En tout qu'a merci pour tout tes conseils je vais essayé d'en tiré profit

**CinePhil** · 29/10/2008, 22h53

Envoyé par rif15

j'ai toujours du mal a imaginer le traitement de ma contrainte de nombre de visionnage par catégorie

Je dirais que c'est une contrainte logicielle plutôt qu'à modéliser en base de données.

Plusieurs scénarios utilisateurs sont possibles :
- Affichage du nombre de visionnages gratuits disponibles sur l'interface utilisateur. Il suffit d'une requête dans la BDD pour le savoir.
- Choix d'un visionnage par le membre et vérification par le système, à l'aide d'une requête, qu'il n'a pas encore atteint son quota de gratuit.

**rif15** · 30/10/2008, 12h51

ok effectivement, j'ai un peu de mal a bien séparer traitement et modéle.

Dans mon 1er projet j'avais dans ma table membre un champ "cat1" avec le nombre de visionnage gratuit, puis un champ "cat1acheter" avec le nombre de visionnage acheter, mais du coup a chaque catégorie rajouter sa me faisait 2 champ a rajouter, et avec une quinzaine de catégorie sa n'était pas trés pratique. J'ai d'ailleur bien comprit maintenant que sa n'était pas bon.

Niveau traitement logiciel, lorsqu'un membre tenter de regarder une video, je récuperer la valeur du champ "catégorie" concerner, je vérifier qu'il était différent de 0, auquel cas je vérifiais le champ "catacheter", je décrementer le champ utilisé de 1.(chaque jour a 00h les champ "catgratuite" revenait a leur valeur inital)

D'aprés ce que je comprend, c'est ce principe que tu conseil, mais du coup ces par rapport a "visionner" qu'il faut traiter les informations.

Par exemple:
un membre se connecte pour la 1ére fois du jour et va sur la catégorie A, je rentre une ligne dans visionner avec l'id membre, l'id de la catégorie A, et le nombre de visionnage effectué (0 d'origine).
Le membre veut regarder une vidéo de la catégorie A, je vérifie le nombre de visionnage effectué par rapport au nombre de visionnage autorisé pour la catégorie donné, si différent je lance la vidéo et incrémente le nombre de visionnage.
Si il veut regarder une vidéo de la catégorie B, on reprend les étapes depuis le début.
Si il veut de nouveau regarder une video de la catégorie A, on vérifie que sa ligne d'enregistrement existe (si oui, il s'est donc déja rendu sur la catégorie aujourd'hui), et on reprend a partir de la 2éme étape.

C'est vrai que ce message est plus traitement, mais j'aurais voulu savoir si la logique etait bonne, ou si il y avait justement des soucis et des choses a reprendre (pour pouvoir avoir le traitement voulu) au niveau du mcd.

Je vous remercie d'avance

**CinePhil** · 30/10/2008, 14h31

Pourquoi créer une ligne de visionnage quand le membre va visiter une catégorie alors qu'il n'a encore rien visionné ?
Tu n'as besoin du nombre de visionnages effectués qu'à partir du moment ou il choisit effectivement de visionner quelque chose.
Et à la limite, inutile de créer une colonne pour ça : une simple requête suffit. Un trux du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT COUNT(*)
FROM visionnages
WHERE idMembre = 123 AND categorie = 1 AND datevisionnage = CURRENT_DATE

**rif15** · 30/10/2008, 15h17

oui c'est vrai qu'inserer la ligne avant le visionnage n'est pas bon, car le membre peut trés bien repartir de la catégorie sans rien regarder, et du coup j'ai insérer une ligne pour rien.

Ta méthode de compter les enregistrements (si je comprend bien la requete) est tout a fait cohérente, et évite un nouveaux champ. Par contre cette table devrait contenir beaucoup d'enregistrement (car j'espere que sa va marcher), en me basant sur mon premier projet, puis sur les concurrents, une estimation porte a 200 000 les visionnages d'un jour (si le succés est au rendez vous bien sur, mais je travaille pour).

Je me demandez donc si avec ce nombre d'entré, le comptage comme tu me la indiqué est optimum, ou si un champ "limit" (incrémenter) change quelque chose :s

J'avoue que c'est une question que je me pose, peut etre que sa ne change rien du tout :s je ne sait pas du tout

**CinePhil** · 30/10/2008, 15h38

A 6 millions de lignes par mois, ça commence à faire beaucoup. A moins que, comme tu accorde un quota de visionnages gratuits par jour, tu n'archives chaque nuit la journée passée et que ta table utile n'aie en fait qu'environ 200 000 lignes tout le temps.
Un comptage sur 200 000 lignes d'une table indexée correctement est très rapide.

Un peu de lecture encore pour t'aider à optimiser ta base de données et tes requêtes :
http://sqlpro.developpez.com/optimisation/indexation/