Devrais-je utiliser une table séparée pour stocker les utilisateurs en ligne ou devrais-je simplement utiliser des champs supplémentaires dans la table des membres existants?

Question

Je travaille sur un système en ligne qui permet aux utilisateurs d’interagir socialement. Il sera bien sûr important de pouvoir identifier les utilisateurs qui sont en ligne. Je sais que HTTP est sans état et je sais utiliser des sessions. Je vais donc devoir accomplir cela en comparant la dernière heure d'activité d'un utilisateur à une heure d'expiration arbitraire.

Ma dernière question est la suivante: Devrais-je simplement ajouter des champs à la table des membres existants ( last_active_time , is_user_online , hide_online_status , etc.) OU serait-il préférable de conserver ces informations dans un tableau séparé? Mon idée initiale est d’utiliser le tableau existant pour plus de simplicité. Outre le niveau de complexité, quels sont les avantages / inconvénients de l’un par rapport à l’autre?

Answer 1

Je maintiendrais cela dans un tableau séparé. Si vous avez un million d'utilisateurs et que vous voulez savoir qui est en ligne, vous ne voulez pas scanner ce tableau encore et encore pour trouver cette information. Votre " en ligne " La table est relativement petite et vous pouvez avoir un travail qui la recherche périodiquement pour ceux qui ne sont pas entrés depuis environ 5 minutes, puis supprimez-les simplement de la table en ligne et mettez à jour tout élément nécessaire dans la table des membres pour "last_seen". ;

Answer 2

Créer une nouvelle table.

Premièrement, il y a la raison philosophique, à savoir qu'un objet (lire: table) doit avoir un but. Cela devient beaucoup flou dans la conception logique des bases de données, mais c'est néanmoins un bon principe.

Mais les véritables raisons viennent de la conception physique: premièrement, on peut supposer que le nombre d’utilisateurs connectés à un moment donné est bien inférieur au nombre total d’utilisateurs, de sorte que les besoins en stockage sont moindres. Et des exigences de stockage moins importantes se traduisent directement par une charge réduite sur la base de données, tout simplement parce que vous avez moins de blocs à lire et à mettre à jour.

De plus, si vous mettez ces données dans votre table principale, ces blocs seront dispersés sur un espace beaucoup plus grand et le contenu des blocs augmentera et diminuera continuellement à mesure que vous modifierez les données.

Enfin, vous aurez probablement besoin de quelques index, par exemple pour savoir qui est en ligne maintenant. Et ces index vont (1) occuper encore plus d’espace, (2) créer encore plus de blocs sales éparpillés qui doivent être écrits physiquement sur le disque, et (3) introduire un point de conflit de mise à jour.

Answer 3

Je pense que cela dépend du nombre d'utilisateurs auxquels vous vous attendez. S'il n'y a que quelques milliers d'utilisateurs, je voudrais simplement faire du statut en ligne un attribut d'utilisateur, dans la table des utilisateurs. S'il doit y avoir plus que cela, alors vous voudrez une table online_users et conserverez ces informations là, avec une clé étrangère dans la table principale utilisateurs. Pour bénéficier des avantages (mentionnés par les affiches ci-dessus), vous souhaiterez qu'une tâche s'exécute toutes les quelques heures environ pour supprimer les utilisateurs inactifs de la table online_users.