Magasin 2-dim table de présence dans la base de données?

Question

Nous avons une application Web, soutenue par une base de données MySQL.

Une partie du système que nous codons nous oblige à stocker la présence (c'est-à-dire oui/non) aux sessions pour les utilisateurs pour chaque jour de la semaine. Par exemple, nous devrions stocker du lundi au vendredi, puis pour chaque jour, le matin, le déjeuner, l'après-midi, les sessions du soir, etc. Donc, essentiellement, c'est un tableau de 2-dim.

Je me demandais quel est le moyen le plus propre de stocker cela dans la base de données?

À l'heure actuelle, la personne qui travaille sur ce point semble pencher pour stocker cela comme un int pour chaque jour, avec 1 représentant la participation et 0 représentant ne pas assister. Je pense que le moyen de faire est d'utiliser un masque de bits (par exemple 13 pour 1101, donc toutes les sessions sauf l'après-midi). Ils sont juste en train de stocker en tant que 0 et 1 pour une raison étrange.

Je pensais qu'il pourrait être plus facile de le stocker comme une liste de bools (bits/tinyints), par exemple. monday_morning, lundi_lunch, lundi_afternoon etc., car il est sémantiquement plus "correct" (je pense?), il sera probablement plus facile à étendre/maintenir, et je semble aussi être le seul dans l'équipe avec une idée de comment faire des opérations de bits ... lol.

Une autre façon que je pensais était juste d'avoir un 1: tableau 1 pour chaque utilisateur, avec une liste de tous les temps, ils sont assister, par exemple. Efficacité de cette approche? (Je ne sais pas quel genre de modèles de lecture/écriture, mais je devine une répartition assez égale de lecture/modification).

Quelles sont les recommandations à ce sujet? Ou y a-t-il de meilleures façons de stocker ces données? En outre, en note de côté, il s'agira probablement d'un booléen - il serait douteux que nous ayons besoin de stocker plus d'états que d'assister/de ne pas assister à la table, et si nous le faisons, nous sommes prêts à re -travaille le schéma. Ou est-ce que les gens suggèrent fortement d'aller sur les bits?

Cheers, Victor

Answer 1

Votre deuxième approche (les colonnes individuelles) est « plus juste » en ce sens qu'il ne viole pas la première forme normale. L'approche par masque de bits, car vous stockez plus d'une valeur dans une seule colonne (vous stockez des valeurs pour plusieurs sessions). Ne pas stocker un bit en interne. Vous n'allez pas voir de diminution du stockage sur, par exemple, un tinyint (le moteur ne va pas allouer exactement un bit pour vous, cela limitera simplement les valeurs acceptables). Vous pouvez également utiliser un tinyint et vous donner un peu de répit.

Modifier

Comme l'a souligné Mark, si vous avez plusieurs colonnes bit il peut les emballer dans un seul octet, mais se soucier de savoir si les données prend un octet ou quatre est probablement une optimisation prématurée. La solution la plus normalisée est celle suggérée où vous avez une table individuelle qui indique les sessions auxquelles le participant a participé. Si vos sessions sont réellement corrigées, j'aurais probablement des colonnes séparées pour chaque session sur le masque binaire ou la solution entièrement normalisée.

1. Le masque de bits masque les données et nécessite des opérations au niveau du bit (évidemment).Ceux-ci peuvent être source de confusion dans la syntaxe de la requête, puisque vous utilisez plusieurs fois les mots or et and. Cette approche ne peut pas non plus être indexée, donc trouver tous les participants qui ont participé, par exemple, à la matinée ou aux sessions du matin et du soir nécessitera un scan de table à chaque fois.

2. La solution entièrement normalisée compliquera les requêtes des données. Bien qu'il supporte l'indexation, il faudra une jointure complète pour chaque type de session que vous voulez vérifier.

L'approche à une colonne par session semble être la meilleure solution. Vous ne gérez toujours qu'une seule ligne de données, mais vous pouvez également interroger avec une syntaxe significative et tirer parti des index.

Answer 2

Je voudrais le normaliser et avoir trois tables: utilisateurs, sessions et sessions_attended. Les utilisateurs contiendraient des informations sur l'utilisateur, les sessions contiendraient des informations sur la session et sessions_attended serait une table de jointure indiquant les sessions auxquelles l'utilisateur a participé. Indexez vos tables correctement et les jointures résultantes devraient être assez efficaces.

select users.name, sessions.name 
from users u join sessions_attended a on u.user_id = a.user_id 
     join sessions s on s.session_id = a.session_id 
where sessions.course = ...some course id...