Organisation de BDD pour forum

18 déc. 2005, 01:04

Bonsoir tout le monde,

Voilà, je comence la création d'un forum "sur mesures". Mais concernant l'optimisation (le site devant accueillir pas moins de 30000 inscrits dont 600 en ligne en même temps), je suis un peu quiche...
voici mes champs :

id ==> id utilisateur
login ==> son pseudo
password ==> son mdp sur 32 caractères (md5)
rank ==> 0, 1, 2 ou 3
assoc_register ==> 0 ou 1
mail ==> adresse email
register_date ==> timestamp date d'inscription
last_connexion_date ==> timestamp date de dernière connexion
verification_number ==> chaîne codée sur 32 caractères (md5)
passions ==> liste des id de forums auxquels l'utilisateur est inscrit
moderation_passions ==> liste des id de forum auxquels l'utilisateur est modérateur
birthday_date ==> date d'anniversaire (timestamp)
last_birthday_mail ==> dernière année d'envoi de l'e-mail d'anniversaire sur 4 chiffres)
sexe ==> 0, 1 ou 2
ville ==> ville sur max 40 caractères
description ==> profil du membre

Donc j'aurai souhaité avoir ce que vous me conseillez comme type pour chaque champ. J'ai déjà looké tous les types et choisi, mais je souhaiterais avoir l'avis d'autres pros sur le sujet

Merci d'avance

18 déc. 2005, 01:16

Ce qui me choque à première vue, c'est les champs qui correspondent à des listes d'id. Tu souhaites stocker plusieurs id dans le même champ?

18 déc. 2005, 01:28

Ce qui me choque à première vue, c'est les champs qui correspondent à des listes d'id. Tu souhaites stocker plusieurs id dans le même champ?

Effectivement...
Ceci peut se changer en plusieurs champs, mais je trouvais pas ça super niveau optimisation...

Voici après une tite correction

id ==> id utilisateur
login ==> son pseudo
password ==> son mdp sur 32 caractères (md5)
rank ==> 0, 1, 2 ou 3
assoc_register ==> 0 ou 1
mail ==> adresse email
register_date ==> timestamp date d'inscription
last_connexion_date ==> timestamp date de dernière connexion
verification_number ==> chaîne codée sur 32 caractères (md5)
passion_1 ==> id de forum auxquel l'utilisateur est inscrit
passion_2 ==> id de forum auxquel l'utilisateur est inscrit
passion_3 ==> id de forum auxquel l'utilisateur est inscrit
passion_4 ==> id de forum auxquel l'utilisateur est inscrit
passion_5 ==> id de forum auxquel l'utilisateur est inscrit
mod_passion_1 ==> 1 si l'utilisateur est modérateur
mod_passion_2 ==> 1 si l'utilisateur est modérateur
mod_passion_3 ==> 1 si l'utilisateur est modérateur
mod_passion_4 ==> 1 si l'utilisateur est modérateur
mod_passion_5 ==> 1 si l'utilisateur est modérateur
mod_general ==> 1 si l'utilisateur est modérateur
birthday_date ==> date d'anniversaire (timestamp)
last_birthday_mail ==> dernière année d'envoi de l'e-mail d'anniversaire sur 4 chiffres)
sexe ==> 0, 1 ou 2
ville ==> ville sur max 40 caractères
description ==> profil du membre

Maintenant, mod_passion peut être mis dans passion (passion_1|mod_passion_1)
C'est quoi la meilleure solution, tout en sachant que l'utilisateur sera inscrit dans 5 forums au choix ?

18 déc. 2005, 02:37

J'aime bien cette représentation:

...
sexe ==> 0, 1 ou 2
...

1 => Homme
2 => FEMME
3 => NEUTRE ? DIVERS ?

18 déc. 2005, 02:44

J'aime bien cette représentation:

...
sexe ==> 0, 1 ou 2
...

1 => Homme
2 => FEMME
3 => NEUTRE ? DIVERS ?

0 ==> un peu des deux / indéfini
1 ==> homme
2 ==> femme

Ptetre un ptit avis à proposer sur ma structure Truc ?

18 déc. 2005, 11:45

Pour les liste de valeurs (que ce soit des id ou du texte tu as deux solutions) :

- Ta liste de valeur est fixe et ne bougera pas (ou alors très rarement), dans ce cas tu utilises un type ENUM (null/1 choix parmis les valeurs) ou SET (null/1 ou plusieurs choix).

Code : Tout sélectionner

passions SET('p1','p2','p3','p4','p5') default NULL

- Ta liste est dynamique, tu passes par une table intermédiaire

Code : Tout sélectionner

user
-------------
id_user
etc...

user_passions
-------------
id_passion
id_user

passions
-------------
id_passion
etc...

19 déc. 2005, 01:19

Pour les liste de valeurs (que ce soit des id ou du texte tu as deux solutions) :

- Ta liste de valeur est fixe et ne bougera pas (ou alors très rarement), dans ce cas tu utilises un type ENUM (null/1 choix parmis les valeurs) ou SET (null/1 ou plusieurs choix).
Code : Tout sélectionner
passions SET('p1','p2','p3','p4','p5') default NULL
- Ta liste est dynamique, tu passes par une table intermédiaire
Code : Tout sélectionner
user ------------- id_user etc... user_passions ------------- id_passion id_user passions ------------- id_passion etc...

En fait l'utilisateur devra choisir cinq passions parmi plus de 100...
donc par table ou enum/set ce sera chaud je pense...
Je pense que la solution de créer cinq champs passion dans la table et les numerotant est la meilleure non ?
De nouvelles passions apparaitront au fur et à mesure, donc aucune liste est fixe hormis les cinq passions choisi par l'utilisateur. A ceux-ci seront accordés ou non des droits de modération (les cinq soit choisis separément) + pour le general.

Donc pour les passions:
- soit je fais cinq champs contenant chacun l'id d'un forum
- soit je fais un champ avec cinq valeurs separées par un caractère alphabétique
- soit j'enregistre cela dans un tableau 2 dimensions

pour les options de modération:
- soit six champs contenant chacun une valeur booléenne
- soit un champs avec six valeurs binaires concatennées
- soit un tableau 2 dimensions avec valeur booléenne à l'intérieur

Qu'en pensez-vous ?

24 déc. 2005, 01:27

Je ne pourrais trop te te conseiller de normaliser tes tables, les listes valeurs stockées dans un champ, c'est très vite la galère...
Imagine qu'un jour, tu souhaites ajouté une fonction permettant de rechercher tous les membres ayant une passion communes, tu vas être obliger d'attaquer les champs pour rechercher celui qui contient une des valeurs, ce qui sera très vite très lourd, surtout si tu arrives à 30000 membres.
Avoir des tables en plus, ne prendra pas plus de place, au final, que d'avoir une table avec beaucoup de champs qui ne seront souvent pas rempli en fonction du profil du membre.

De manière générale, il ne faut pas avoir peur du nombre de table, une grosse application de gestion, peut contenir jusqu'à plus de 1000 tables sans aucun problême.

24 déc. 2005, 04:01

Je ne pourrais trop te te conseiller de normaliser tes tables, les listes valeurs stockées dans un champ, c'est très vite la galère...
Imagine qu'un jour, tu souhaites ajouté une fonction permettant de rechercher tous les membres ayant une passion communes, tu vas être obliger d'attaquer les champs pour rechercher celui qui contient une des valeurs, ce qui sera très vite très lourd, surtout si tu arrives à 30000 membres.
Avoir des tables en plus, ne prendra pas plus de place, au final, que d'avoir une table avec beaucoup de champs qui ne seront souvent pas rempli en fonction du profil du membre.

De manière générale, il ne faut pas avoir peur du nombre de table, une grosse application de gestion, peut contenir jusqu'à plus de 1000 tables sans aucun problême.

oki, merci du tuyau

C'est surtout suite aux optimisations conseillé sur le tuto phpfrance, ou il faut privilégier une taille fixe

donc bon, je pense donc ne pas retenir la solution de damien, vu que le nombre de passions selectionnées ne changera pas.
je ferais donc un champ tinyint(4) pour inscrire l'id de la passion selectionnée, et donc 5 champs tinyint(4) pour les cinq passions et6 champs tinyint(1) pour la modération (1 general + 5 passions)

Ca vous paraît correct ?

24 déc. 2005, 11:54

C'est déja mieux qu'une liste de valeurs dans un champ, mais ce n'est pas encore à mes yeux le meilleur choix.
Il faut savoir si il n'y a vraiment aucune chance d'augmenter le nombre de passion, ensuite le nombre moyen de passion que choisiront les membres, si beaucoup n'en choisiront qu'une ou deux, tu auras une perte de place.
Ensuite, avoir 6 champs dans une table, complexifie les opérations de recherche, chaque champ devant être traité séparement.
Franchement, si j'étais toi, je normaliserais complétement (4ème niveau

24 déc. 2005, 12:03

Même avis que iclo. Créer une tabke intermédaire qui ne va stocker que le couple id_membre-id_passion.

Au jour d'aujourd'hui, tu penses à 6 passions mais rien ne t'assure que dans 6 mois, tu n'en veuilles que 2 ou bien 10. Avec ta solution, il faut changer les tables, changer les requetes alors qu'avec une table intermédiaires, il te suffit de rajouter des enregistrements et la requete de recherche sera la même

exemple de requete pour sélectionner les membres de la passion id=0

Code : Tout sélectionner

SELECT id_membre
FROM users
WHERE passion_1 = 0
  OR passion_2 = 0
  OR passion_3 = 0
  OR passion_4 = 0
  OR passion_5 = 0

Même requete mais avec une table intermédiaire

Code : Tout sélectionner

SELECT id_membre
FROM users_passion
WHERE id_passion = 0

Tu remarques que même si tu décide d'ajouter des passions à tes membres, la seconde requête fonctionne mais la 1ere laisse des passion sur le carreau

25 déc. 2005, 01:26

Ouef, mais justement, le but c'est de ne pas avoir plus de 5 passions (choix stratégique qui ne bougera pas). Donc de toute façon je peux faire ça avec une table intermédiaire, y'a pas de soucis.

Organisation de BDD pour forum

Qui est en ligne