Je vais donc essayer d'être le plus clair possible
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 ) 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 ).
Merci