J'ai beaucoup travaillé avec les bases de données relationnelles et je pense comprendre assez bien les concepts de base d'une bonne conception de schéma. J'ai récemment été chargé de reprendre un projet où la base de données avait été conçue par un consultant hautement rémunéré. S'il vous plaît laissez-moi savoir si mon intestin instinct - "WTF ??!?" - est justifié, ou est-ce un gars si génial qu'il opère hors de mon royaume?
DB en question est une application interne utilisée pour saisir les demandes des employés. En regardant une petite partie de celle-ci, vous avez des informations sur les utilisateurs et des informations sur la demande en cours. Je concevrais ceci comme si:
Table utilisateur:
UserID (primary Key, indexed, no dupes)
FirstName
LastName
Department
Table de demande
RequestID (primary Key, indexed, no dupes)
<...> various data fields containing request details
UserID -- foreign key associated with User table
Simple, non?
Le consultant l'a conçu comme suit (avec des exemples de données):
Tableau d'utilisateurs
UserID FirstName LastName
234 John Doe
516 Jane Doe
123 Foo Bar
DépartementsTable
DepartmentID Name
1 Sales
2 HR
3 IT
UserDepartmentTable
UserDepartmentID UserID Department
1 234 2
2 516 2
3 123 1
RequestTable
RequestID UserID <...>
1 516 blah
2 516 blah
3 234 blah
La base de données entière est construite comme ceci, avec chaque donnée encapsulée dans sa propre table, avec des ID numériques reliant tout. Apparemment, le consultant avait entendu parler d’OLAP et souhaitait connaître la «vitesse de recherche des nombres entiers».
Il dispose également d'un grand nombre de procédures stockées pour faire référence à toutes ces tables.
Cette conception est-elle valide pour une base de données SQL de taille petite à moyenne?
Merci pour les commentaires / réponses ...
Réponses:
Cela me semble parfaitement sensé. C'est juste très normalisé, ce qui confère beaucoup de flexibilité que vous n'auriez pas autrement. Les données dénormalisées sont une douleur dans le dos.
la source
Je ne pense pas que ce soit une WTF soit garantie ou que le type fait tout type de conception de génie fou - c'est une normalisation de base de données assez standard.
La raison pour la table de département est que si vous ne mettez pas les départements dans une table séparée, vous devrez traiter les utilisateurs dans les départements "Ventes", "Ventes", "Vendeurs", "Voiles" et "Ventes", sauf si vous faites quelque chose pour l'empêcher. Et avoir la table supplémentaire est (une partie de) la meilleure façon que je connaisse pour le faire.
Qu'il y ait ou non une table UserDepartment est un appel plus difficile, ce qui signifie bien sûr qu'aucune des décisions prises n'est folle. D’un côté, c’est pénible lorsque toute la conception et la logique de votre table ont supposé un département par utilisateur, puis que cela change. D’autre part, faire une jointure supplémentaire sans raison pendant des années et des années est une possibilité réelle et également pénible.
Personnellement, je conviens avec vous que la table UserDepartment est probablement excessive. Même s'il est inclus, il est probable qu'avec le temps, les gens écriront des requêtes supposant qu'il n'y a qu'un seul utilisateur par département. Vous vous retrouverez ainsi avec le pire des deux mondes: une jointure supplémentaire sans raison avant d'avoir besoin de la table, et le code ne fonctionnant pas de toute façon une fois plus d'un service par utilisateur est autorisé.
EDITER - Si les règles de gestion sont claires, la détermination de la relation plusieurs à plusieurs est un facteur déterminant. Si vous ne savez pas comment un utilisateur de plusieurs départements fonctionnerait, il serait inutile d'ajouter la table, car votre code ne peut pas correctement traiter les cas où un utilisateur appartient à plusieurs départements.
Imaginez que vous ayez autorisé plusieurs départements par utilisateur, au cas où. Vous avez ensuite implémenté une règle de gestion pour l'attribution de commissions, basée sur le service. Ensuite, plusieurs départements ont été autorisés. Heureusement, vous avez également eu la clairvoyance d’écrire votre code de commission de manière à en tenir compte. Malheureusement, vous avez ajouté les commissions de chaque département pour les utilisateurs des deux. La direction souhaitait que vous vous basiez sur le rôle des personnes pour chaque vente. Alors, à quoi bon avoir la table à l'avance? Qu'en est-il des autres tables que vous aviez "juste au cas où" qui ne sont jamais nécessaires?
PLUS TARD - Une autre raison pour laquelle le consultant aurait peut-être voulu ajouter tous ces tableaux intermédiaires est abordée dans cette question complémentaire , dont les réponses donnent certaines raisons pour lesquelles la refactorisation d'une base de données est généralement plus difficile que le code de refactorisation, ce qui aurait tendance à vous pousser vers l'approche "mettre dans toutes les tables que vous pourriez avoir besoin".
la source
Si l'exigence est d'avoir plusieurs départements par utilisateur, cette conception est logique. Le seul inconvénient est d'
UserDepartmentTable
avoir une clé de substitutionUserDepartmentID
inutile (créez simplement laUserId
etDepartmentId
une clé primaire composite).Si un utilisateur n'appartient qu'à un seul département, votre conception a du sens (bien qu'une table de consultation de département reste une bonne chose).
la source
Certaines exigences ne sont pas claires dans votre question. La réponse correcte dépend de ce que veut votre client - Si j'étais vous, je demanderais au client ce qu'il en est:
0-Quelle est la différence entre un utilisateur et un employé?
1-En supposant qu'un employé = utilisateur, que se passe-t-il si un employé change de département?
2-Un groupe d’employés peut-il faire une demande?
3-Un employé peut-il appartenir à plusieurs départements? Qu'en est-il du PDG
4-Y a-t-il un sous-ensemble d'employés autorisés à faire des demandes?
5-Qu'advient-il de la demande lorsqu'un enregistrement d'employé est supprimé (si jamais)?
6-Pouvez-vous supprimer une demande? Que se passe-t-il lorsque la demande est supprimée (veillez à ne pas supprimer l'enregistrement d'employé par RI)
7-L'employé peut-il faire la "même" demande plus d'une fois (définir la "même")
8-Comment traiter les demandes des employés lorsqu'ils quittent l'entreprise (annuler leurs demandes ou supprimer les demandes?)
Il peut y avoir plus de questions, mais mon point est que la solution dépend d' exigences précises et de la portée du projet. Une fois que cela est déterminé, le schéma peut être dérivé directement. En conséquence, les deux solutions présentées peuvent être correctes.
la source
J'aimerais ajouter quelques notes explicites expliquant certains des avantages potentiels de l'utilisation d'une table de jointure de la même manière que votre consultant hautement rémunéré.
UserDepartmentTable.Department
n'est pas plus difficile que de rechercher une autre colonne duUser
tableau.UserDepartmentTable.Active
false et crée une nouvelle association active). Il est également possible d'avoir un versioning d'association de département avec le modèle à deux tables (utilisateur et département uniquement), mais il est plus difficile et nécessite l'ajout d'au moins une colonne ou des acrobaties de base de données afin d'éviter la duplication de clés primaires.Cela étant dit, il y a plusieurs raisons de NE PAS faire ce que votre consultant hautement rémunéré a fait.
la source
Sans une structure complète d'informations nécessaires, je ne peux pas dire si c'est terrible ou non. Mais au moins, la pièce présentée n’est pas de type "WTF". Cela semble juste être la 3-ème forme normale de structure de données (enfin, théoriquement, nous avons aussi les 4 et 5 également)
Certaines discussions peuvent avoir lieu pour UserDepartmentTable entre deux écoles de clés "naturelles" et "artificielles" dans la pièce illustrée. Rien de plus, comme je peux le voir
La normalisation est de bonne règle DB-développeur / concepteur pour beaucoup de raisons, * de * normalisations sont utilisés parfois au milieu de l ' évolution de la vitesse-gagnant la plupart du temps
la source