Discussion :

[koven]

Bonjour !

Je viens à vous aujourd'hui pour des questions d'optimisations sur ma base de données.

Tout d'abord, je souhaite mettre en place un système de grade d'administration (exemple : modérateur, admin, super admin)

J'aurai souhaité savoir si le mieux était de mettre le numéro du grade dans la table membre (id_membre, login_membre, pass_membre, grade_membre)

ou

créer une table administration_membre (id, id_membre, id_grade)

Sachant qu'un membre n'aura qu'un seul et unique grade


Par ailleurs, mon système d'activation de membre s'effectue de la sorte :
- Création d'un code d'activation, insertion de ce code dans une table contenant l'id du membre
- Si activation, mettre la colonne 'UT_actif' à 1 (utilisateur_actif)

J'ai donc une table T_USER_UT(UT_id, UT_login, UT_pass, UT_actif)

Est-ce plus coûteux de conserver ce système ou de créer une table 'membre_actif' qui contiendrait la liste des membres dont le compte a été activé ?


J'en profite aussi pour vous demander :
Un membre peut ajouter des informations personnelles, mais qui ne seront visibles que sur une partie spécifique d'un profil (ex : membre/48/more_info)

Vaut il mieux séparer les informations complémentaires des informations principales dans deux tables distinctes (soit T_USER_UT et T_INFO_USER_IU) ou tout mettre dans une seule table ?


En ce qui concerne les logs, je prévois de créer des tables de logs qui me permettra de tracer des actions, par exemple si un membre se connecte, j'ajoute dans une table de log son ip, heure, id soit T_LOG_LOGIN_TL (TL_id, TL_ip, TL_id_ut, TL_heure)

Ma question est donc, est-il conseillé de séparer la base de donnée contenant ces logs de celle de mon site principal ? Etant donné la différence de transferts d'informations entre les deux. Ainsi est il aussi possible de créer une vue 'globale' accessible dans plusieurs base de données ?


Enfin, dernière question concernant les verrous. J'aurai simplement souhaité savoir si, dans le cas d'une application multi utilisateur, on applique un verrou à chaque insert/update dans la base de donnée ? (Cela obligerait-il à appeler des procédures à chaque insertion ou mise à jour) ?


Par avance, un grand merci pour les réponses apportées, j'essaie d'optimiser au mieux ma base de donnée pour mon projet et vos réponses me seront très utiles

Koven

[CinePhil]

Tout d'abord, je souhaite mettre en place un système de grade d'administration (exemple : modérateur, admin, super admin)

J'aurai souhaité savoir si le mieux était de mettre le numéro du grade dans la table membre (id_membre, login_membre, pass_membre, grade_membre)

ou

créer une table administration_membre (id, id_membre, id_grade)

Sachant qu'un membre n'aura qu'un seul et unique grade

Si tout membre a un grade, tu as cette association :
membre -1,1----avoir----0,n- grade

Il faut alors mettre une clé étrangère référençant l'identifiant du grade dans la table des membres.

Si par contre il y a des membres sans grade, tu as cette association :
membre -0,1----avoir----0,n- grade

La bonne modélisation est alors de créer une table associative :
tj_mbr_avoir_grd_mag (mag_id_membre, mag_id_grade)

Par ailleurs, mon système d'activation de membre s'effectue de la sorte :
- Création d'un code d'activation, insertion de ce code dans une table contenant l'id du membre
- Si activation, mettre la colonne 'UT_actif' à 1 (utilisateur_actif)

J'ai donc une table T_USER_UT(UT_id, UT_login, UT_pass, UT_actif)

Est-ce plus coûteux de conserver ce système ou de créer une table 'membre_actif' qui contiendrait la liste des membres dont le compte a été activé ?

Si tu as déjà une table contenant l'id du membre et son code d'activation, tu n'as pas besoin d'autre chose. Les membres actifs sont ceux ayant un code d'activation.

Un membre peut ajouter des informations personnelles, mais qui ne seront visibles que sur une partie spécifique d'un profil (ex : membre/48/more_info)

Vaut il mieux séparer les informations complémentaires des informations principales dans deux tables distinctes (soit T_USER_UT et T_INFO_USER_IU) ou tout mettre dans une seule table ?

Si "more_info" est une colonne fourre tout et unique pour chaque membre, tu peux laisser comme ça.
Si par contre le membre peut ajouter X informations personnelles extrayables individuellement, il faut une table pour ces infos.
te_info_membre_imb (imb_id, imb_id_membre, imb_titre_info, imb_contenu)

En ce qui concerne les logs, je prévois de créer des tables de logs qui me permettra de tracer des actions, par exemple si un membre se connecte, j'ajoute dans une table de log son ip, heure, id soit T_LOG_LOGIN_TL (TL_id, TL_ip, TL_id_ut, TL_heure)

Ma question est donc, est-il conseillé de séparer la base de donnée contenant ces logs de celle de mon site principal ? Etant donné la différence de transferts d'informations entre les deux. Ainsi est il aussi possible de créer une vue 'globale' accessible dans plusieurs base de données ?

Quel SGBD utilises-tu ?
Normalement, on peut faire des requêtes entre plusieurs schémas d'une même base de données. Si tu utilises MySQL, ça peut se faire entre plusieurs bases de données sur le même serveur puisque le mauvais MySQL confond la notion de schéma et de base de données.

Enfin, dernière question concernant les verrous. J'aurai simplement souhaité savoir si, dans le cas d'une application multi utilisateur, on applique un verrou à chaque insert/update dans la base de donnée ? (Cela obligerait-il à appeler des procédures à chaque insertion ou mise à jour) ?

Généralement, il y a un utilisateur applicatif unique qui se connecte à la base de données et qui effectue toutes les transactions.
Le mécanisme de verrouillage dépend du SGBD et du paramétrage.

[koven]

Hello

Tout d'abord merci pour les réponses, c'est ce que j'avais plus ou moins mis en place.

Pour les verrous, je pensais pas que c'était entre les utilisateurs de la base de données. Mais effectivement dans mon cas je n'ai qu'une seule connexion donc un seul utilisateur.

Malheureusement oui j'utilise Mysql, fourni de base par mon hébergeur. Mais j'avais pas vraiment cherché niveau requêtes, c'est super simple, il suffit de rajouter le nom de la base de donnée avant la table ex select * from <db>.<table>

Un grand merci en tout cas, je vais pouvoir continuer sur ces bases là

Koven

[CinePhil]

?