Conception d'une base de données pour suivre la fréquentation des étudiants
J'avais un doute concernant la conception d'une table de base de données pour suivre la fréquentation des étudiants. Actuellement, ma table students a au moins 4000 élèves.
La création d'une base de données de présence pour suivre leur présence aura presque 4000*30days*12months => ~ 1,400,000 lignes (en négligeant les vacances/dimanches).
La table de présence aura:
id (INT)
student_id (INT)
course_id (INT)
data (DATETIME)
present/absent (TINYINT, as I'll store 1/0)
comments
J'utilise PHP/MySql. Avec une table qui devient si grande, y a-t-il un autre moyen?
Pour en savoir plus sur l'alternative @Twinkles, je me demande pourquoi vous stockez les étudiants présents et absents dans vos données de fréquentation. Est-ce parce que vous voulez pouvoir générer un rapport qui montre tous les enfants et s'ils étaient absents un jour donné? Il y a une meilleure façon de le faire.
La plupart des systèmes que j'ai vus stockent soit la présence de l'élève (fréquentation positive), soit l'élève est absent (fréquentation négative, bien que rarement désigné par ce nom). La décision quant à l’utilisation dépendait de la structure et des exigences en matière de rapports de l’école (et à qui ils relèvent).
Si votre école est préoccupée lorsque l'élève est absent pour des raisons telles que le suivi des élèves Truant, vous devez utiliser une structure de fréquentation standard (négative). La plupart des écoles K-12 aux États-Unis le font de cette façon.
Si votre école n'accorde des crédits pour les cours qu'après un nombre d'heures vérifié (par exemple Johnny ne réussit pas le cours tant qu'il n'a pas terminé ses cours et assisté à 12 séances de la classe), alors une structure de présence positive pourrait être utilisée.
En supposant que vos données ressemblent à ceci: (Ignorer le course_id dans votre exemple pour plus de simplicité)
Attendance:
id | student_id | date |
------------------------------
1 | 2 | 2013-10-24 |
Students:
student_id | student_name |
-----------------------------
1 | Johnny Johnson |
2 | Bobby Tables |
3 | Suzie Smith |
Pour obtenir un rapport de tous les enfants de votre école et leur statut de fréquentation pour la journée, vous pouvez exécuter une requête comme:
SELECT s.student_id, s.student_name
, CASE WHEN a.id IS NOT NULL THEN 'Absent' ELSE 'Present' END as attendance_status
FROM Students s
LEFT JOIN Attendance a on s.student_id=a.student_id AND a.date = '2013-10-24'
Qui reviendrait:
Result :
student_id | student_name | attendance_status |
-------------------------------------------------
1 | Johnny Johnson | Present |
2 | Bobby Tables | Absent |
3 | Suzie Smith | Present |
Vous définirez très probablement un index sur ID , student_ID et presence. Étant donné que ces trois valeurs sont représentées par 9 octets, l'index entier aura une taille inférieure à 20 Mo et s'intégrera complètement dans votre mémoire. Je ne m'en inquiéterais pas.
Alternative: vous pourriez envisager de ne stocker qu'une rangée pour chaque étudiant qui a manqué le cours.
Cela ressemble à un bon cas pour l'archivage ou la diminution de la granularité. Je soupçonne que les données exactes deviennent moins pertinentes au fil du temps. Ma préférence personnelle serait d'avoir trois niveaux de granularité: quotidien, hebdomadaire et annuel. Une fois que les données ont plus d'une semaine, vous les résumez toutes les semaines. Une fois qu'il a plus d'un an, résumez-le annuellement. J'aurais dit aussi tous les mois, mais la cartographie d'une semaine à l'autre n'est pas précise.