[MySQL] Système de BDD d'un projet (Conception & Optimisation)

Système de BDD d'un projet (Conception & Optimisation) [MySQL] - SQL/NoSQL - Programmation

Marsh Posté le 07-04-2006 à 16:30:01    

Je vais donc essayer d'être le plus clair possible  :ange:  

 

Le but de l'application est de fournir des statistiques en GRH aux utilisateurs et donc de se positionner en fonction de leur secteur d'activité, secteur géographique, etc.

 

Donc, en gros, l'utilisateur s'inscrit et un questionnaire (avec les 100 questions  :sweat:  ) lui est fourni. Il y répond et les données sont stokées sur la BDD.
Ensuite, il lui est mis a disposition plusieurs outils statistiques (dc ya de l algorithme derrière) pour comparer ses données à la base de données selon les critères qu'il voudra (grace aux données des autres utilisateurs notemment). Chaque trimestre, il sera invité de nouveau à faire un questionnaire afin de :
 
 

  • Réactualiser ses informations  

Permettre un suivi de l'évolution de ses données (calcul de variations)

 


Dc, les réponses aux questionnaires sont enregistrées pour chaque questionnaire (selon la date) et la BDD n'est pas réactualisée en fait.
Ex : L'utilisateur A repond à son premier questionnaire au mois de mars (enregistré donc comme questionnaire 1). Au mois de mai il décide d'en remplir à nouveau : ses réponses sont donc enregistrées dans le questionnaire 2. Ainsi on pourra calculer l'évolution des données qu'il a fourni entre Mars et Mai.
Pour les comparaisons multicritères avec les autres utilisateurs, on utilisera les derniers questionnaires rendus pour chacun, pour l'actualité des informations.

 

Ma question porte donc surtout sur la conception et l'optimisation de ces tables. Je reviens donc sur la première idée de conception :

 

Exemple de ma conception pour le moment :

 

Tables :
Adherent (ID_adherent, nom_adherent, mail_adherent, nom_utilisateur, pass_utilisateur)
Creer (# ID_adherent (unique), # ID_questionnaire (unique), date_questionnaire)
Questionnaire (ID_questionnaire, réponse_1_questionnaire, réponse_2_questionnaire, réponse_3_questionnaire, …)

 

Soit un MLD de la sorte : adherent (1,n) ------ creer ------ (1,1) questionnaire

 

La table adherent correspondant aux informations rentrées à l'enregistrement.
La table crer correspondant à l'mplémentation d'une date lors de la création d'un questionnaire.
Enfin, la table questionnaire correspond à toutes les infos récoltées après remplissage du dit questionnaire.

 

Le problème, c'est que la table questionnaire contient à peu de choses près une centaine de champs, dont voici un classement par catégories (meme si pour le moment je rentre la totalité dans ma table questionnaire) :

 

Profil de l'organisation : 14 champs
Emploi et démographie : 32 champs
Productivité des salariés : 8 champs
Climat social, comportements sociaux et conditions de travail : 10 champs
Gestion du capital humain : 14 champs
Rémunération : 17 champs

 

Dc, ma crainte, de par la presque 100aine de champs de la table questionnaire, on peut imaginer le nombre d'enregistrements qu'elle pourra contenir, et donc la taille de la table par extension.

 

Dc ma question : comment concevoir un meilleur système de table, plus optimiser, alliant vitesse d exécution et facilité d'utilisation (car avec la table questionnaire actuellement, j'ai peur de me paumer dedans qd je devrai créer les script de calcul  :whistle:  ).

 

Merci

Reply

Marsh Posté le 07-04-2006 à 16:30:01   

Reply

Marsh Posté le 07-04-2006 à 16:59:16    

Ta table questionnaire est effectivement mal conçue (illisible, lourde, pas evolutive)
 
Fais plutôt une table "reponse" indexée par l'ID du questionnaire + numero de la réponse, par exemple

Reply

Marsh Posté le 07-04-2006 à 17:04:01    

smaragdus a écrit :

Ta table questionnaire est effectivement mal conçue (illisible, lourde, pas evolutive)
 
Fais plutôt une table "reponse" indexée par l'ID du questionnaire + numero de la réponse, par exemple


 
Pouriez vous être un peu plus explicite s'il vous plait... ca fait des heures que je planche sur la question, et j'ai un peu le cerveau en compote à cette heure.
Merci de votre réponse en tout cas !  :hello:

Reply

Marsh Posté le 07-04-2006 à 17:26:57    

J'ai pensé à une structure de la sorte (mais je crois qu'il y a un pb  :heink: ) :
 
Tables :  
Adherent (ID_adherent, nom_adherent, mail_adherent, nom_utilisateur, pass_utilisateur)  
Creer (# ID_adherent (unique), # ID_questionnaire (unique), date_questionnaire)  
Questionnaire (ID_questionnaire)
Contenir (# ID_questionnaire (unique), # ID_formulaire (unique))
Formulaire (ID_formulaire,# ID_categorie, reponse_1, reponse_2, reponse_3, ...)
Categorie (ID_categorie, libelle_categorie)  
 
Là j'ai décomposé le questionnaire en plusieurs formulaires, 1 par Catégories. Dc un questionnaire sera composé de 6 formulaires, chacun appartenant à une des 6 catégories (voir premier topic).
 
Mais j'ai du oublier qqch là... ça me parait pas bon du tout là  :pfff: .


Message édité par [afc]metos le 07-04-2006 à 17:32:34
Reply

Marsh Posté le 08-04-2006 à 13:07:22    

up

Reply

Marsh Posté le 08-04-2006 à 13:18:22    

c'est pourtant pas compliqué, tu décomposes ta table de réponses  en :
 
Formulaire (ID_formulaire,# ID_categorie)  
ReponseFormulaire(ID_formulaire, ID_reponse, reponse)

Reply

Marsh Posté le 10-04-2006 à 16:23:22    

Après réflexion, je me suis aperçu que répondre à une centaine de questions pouvait être fastidieux.  
Ainsi, je pense "découper" mon questionnaire en 6 parties (correspondant aux 6 catégories de questions).  
 
Est-ce que la structure de BDD suivante vous parait correcte :  
 
Adherent (ID_adherent, nom_adherent, mail_adherent, nom_utilisateur, pass_utilisateur)  
Questionnaire (ID_questionnaire, # ID_adhérent, date_questionnaire, validation_formulaire_1, validation_formulaire_2, validation_formulaire_3, validation_formulaire_4, validation_formulaire_5, validation_formulaire_6)  
formulaire_1 (ID_formulaire_1, # ID_questionnaire, # ID_adherent, valeur1, valeur2, valeur3, ...)  
formulaire_2 (ID_formulaire_2, # ID_questionnaire, # ID_adherent, valeur1, valeur2, valeur3, ...)  
formulaire_3 (ID_formulaire_3, # ID_questionnaire, # ID_adherent, valeur1, valeur2, valeur3, ...)  
formulaire_4 (ID_formulaire_4, # ID_questionnaire, # ID_adherent, valeur1, valeur2, valeur3, ...)  
formulaire_5 (ID_formulaire_5, # ID_questionnaire, # ID_adherent, valeur1, valeur2, valeur3, ...)  
formulaire_6 (ID_formulaire_6, # ID_questionnaire, # ID_adherent, valeur1, valeur2, valeur3, ...)  
 
Ainsi, un questionnaire ne pourra être valide que si les 6 validations des formulaires qu'il contient sont effectives. L'adhérent pourra faire, de ce fait, 1 formulaire à la fois sans pour autant se farcir la centaine de question d'un coup.  
 
 
Cela vous parait viable ?  
Au niveau de l'indexation et et des jointures, quelle est la meilleure solution ?

Reply

Marsh Posté le 10-04-2006 à 16:29:32    

Non, le coup de diviser les 6 formlaires en faisant 6 tables identiques, c'est nul : ça n'a aucune flexibilité et les évolutions seront fastidieuses.
 
Tu peux très bien faire ça en 2 tables comme je l'ai indiqué plus haut.

Reply

Marsh Posté le 10-04-2006 à 17:30:54    

tu devrais regarder comment la BD de l'outil de sondage Nabopoll est structurée. Ca pourrait t'aider...

Reply

Marsh Posté le 10-04-2006 à 17:36:27    

rufo a écrit :

tu devrais regarder comment la BD de l'outil de sondage Nabopoll est structurée. Ca pourrait t'aider...


Je regarde ça... merci !


Message édité par [afc]metos le 10-04-2006 à 17:37:22
Reply

Marsh Posté le 10-04-2006 à 17:36:27   

Reply

Marsh Posté le 12-04-2006 à 16:15:24    

Dc, après pas mal de réflexion en essayant de penser à tous les cas, je suis arrivé à cette structure :
 
USER
user_ID (auto_increment)
user_name
user_mail
user_log
pass_user
 
FORM
user_ID
form_ID (auto_increment)
form_date
form_valid (0 par defaut)
 
CATEGORY (6 catégories, fixe et donc remplit à la main)
category_ID (de 1 à 6)
category_heading
 
VALID
form_ID
category_ID
valid
 
QUESTION (référence la centaine de question, fixe et donc remplit à la main)
category_ID
question_ID (de 1 à x)
question_heading
 
ANSWER
user_ID
form_ID
category_ID
question_ID
answer_value
 
Dc, pour schématiser tout cas, un utilisateur 1 se connecte. Il arrive sur sa page qui référencie tous les formulaires qu'il a rempli et (ou non) le formulaire qu'il a commencé à remplir et qu'il peut finir de compléter, ainsi qu'un bouton de création de nouveau formulaire (accèssible que si il n'y a pas de formulaire déjà entamé).
Si l'utilisateur 1 crée un nouveau formulaire (formulaire 1), il arrive sur une page avec 6 liens sur les 6 catégories de questions qu'il peut remplir. Chaque lien possède un feu : rouge s'il n'a pas encore été validé (et donc cliquable), vert s'il l a été.
Si l'ultilisateur 1 clique sur la catégorie 1 et la remplit, la table ANSWER est remplie par ses réponses et la table VALID obtient une entrée (ici form_ID = 1 / category_ID = 1 / valid = 1). Il est redirigé sur la page des catégories et le feu de la categorie 1 est passé au vert (de par un test sur la table VALID).
Pour savoir si un formulaire a été remplit dans sa totalité (toutes les catégories) et donc valide, un test sur la table VALID est fait (si l'addition des valeurs "valid" sur une selection de "form_ID" (ici 1) est égal a 6). Si le test est positif, alors form_valid = 1 (par defaut 0).
 
 
Qu'en pensez vous ? (désolé si mes explications sont peu claires, mais c'est assez compliqué  :jap: )


Message édité par [afc]metos le 12-04-2006 à 16:28:11
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed