Quelle structure de tables est la meilleure?

Question

Je développe une application de gestionnaire de tâches multi-utilisateur mais j'ai trébuché sur la conception de schéma de base de données. J'ai la table d'utilisateur, la catégorie et bien sûr la table de tâche. Chaque tâche appartient à exactement une catégorie. Donc, dans les mots DDL j'ai besoin d'une relation «un-à-plusieurs» entre la catégorie et la tâche, n'est-ce pas? Aussi, je suis presque sûr que j'ai besoin d'une relation «un-à-plusieurs» entre les entités utilisateur et tâche. (Corrigez-moi si j'ai tort, s'il-vous plait). Quant à la « catégorie - utilisateur » relation, ici je considère sérieusement deux options et je dois vous me dire quel est le bon et pourquoi:

1. La relation « many-to-many », à savoir l'utilisateur peut avoir plusieurs catégories et vice-versa;

2. La relation "un-à-plusieurs" dans laquelle chaque catégorie peut se rapporter à un seul utilisateur. Dans ce cas, dans le tableau des catégories, il y aura beaucoup de lignes avec des noms similaires tels que "travail", "famille" etc. (car il est difficile de trouver quelque chose de nouveau et d'original en ce qui concerne les catégories). Valeur de la colonne "utilisateur".

Quelle approche est commune dans cette situation?

Answer 1

C'est une question délicate, car les deux approches ont des avantages. Vous avez probablement besoin de mieux définir votre problème et ce que vous voulez accomplir.

Je travaille sur un projet similaire, avec une structure comme celle-ci:

• Une table utilisateur, les informations de base
• Une auto liée table de travail, ce qui permet de créer des « projets » (une tâche avec pas de parent) et les tâches dépendantes ("cette tâche ne doit pas commencer avant que la tâche précédente soit terminée")
• Une table d'allocation many-to-many, reliant plusieurs utilisateurs à plusieurs tâches ("ce travail doit être fait par user1 et user2 travaillant ensemble ")

Et voici votre question revient: comment les utilisateurs sont supposés organiser leurs tâches en attente?

• Si votre projet ressemble davantage à une liste de tâches, vous n'avez pas besoin de cette table d'allocation; bâton avec votre « Chaque tâche appartient à exactement une catégorie » déclaration
• Si les utilisateurs devraient être autorisés à créer leurs propres catégories, vous avez probablement besoin de créer une table user-categories, avec des informations de catégorie et une clé étrangère à la table utilisateur
• Si les utilisateurs doivent choisir une catégorie précédemment créée à partir d'une liste commune, vous n'avez pas besoin de cet utilisateur FK
• Quoi qu'il en soit, si les utilisateurs pouvaient catégoriser leurs tâches allouées, cette table de catégories sera une clé étrangère dans la table d'allocation, donc chaque utilisateur peut catégoriser ses propres tâches

Dans mon expérience, vous devriez retarder cette décision de catégorie et demander à vos utilisateurs; ils vous dirigeront dans la bonne direction.

Vous pouvez également créer simplement cette table user-catogories, car elle est plus flexible que l'alternative et ignore cette répétition de données.L'utilisation d'une liste de catégories de base avec une relation plusieurs-à-plusieurs avec les utilisateurs sera probablement une mauvaise idée, car un utilisateur pourrait décider de renommer une catégorie et tous les autres utilisateurs seront affectés par cette action.