2010-12-17 8 views
1

Nous faisons une petite refonte et la consolidation de certaines tables dans une base de données. Là où nous avions autrefois 2 tables, 'administrators' et 'users 'nous combinons maintenant en une seule table appelée 'users'. Pour faciliter cette modification, nous avons créé une table 'user_types' et une table 'user_user_types' qui est la table de liaison un-à-plusieurs entre 'users' et 'user_types'. La raison pour laquelle nous devons utiliser la table 'user_types', c'est parce qu'il y a différents types d'administrateurs, l'un étant un super administrateur qui a accès à tout ce qui se trouve dans notre système. Dans la vieille configuration il y avait un champ peu dans la table 'administrators' appelée 'SiteAdmin' qui a indiqué que cet admin particulier était un super administrateur ou pas. Depuis le passage à ce nouveau système, je pensais qu'il y aurait un type d'utilisateur dans la table 'user_types' qui serait un super administrateur et que nous lierions juste l'utilisateur correct à ce type d'utilisateur dans ces cas-là, mon collègue programmeur dit ici qu'il veut utiliser un champ de bit 'SiteAdmin' dans la nouvelle table 'users'. Je pense que c'est un peu redondant, mais il prétend qu'il y aurait une charge excessive et que le processeur SQL aurait plus besoin de joindre les tables 'users', 'user_types' pour déterminer si un utilisateur particulier était un super administrateur.Quelle est la meilleure façon de structurer ces données dans une base de données?

Ma question est de savoir quel est le meilleur moyen? Est-ce que le coup sur le serveur SQL est si bon en joignant les deux tables qu'il justifie d'ajouter le champ de bit à la table 'users' pour signaler les super-admins?

Merci!

Répondre

3

Votre nouvelle conception semble raisonnable et plus facile à entretenir sur la route. Je doute que la jointure ait un impact sur les performances, d'autant plus que vous demandez probablement le (s) type (s) d'utilisateur une fois par utilisateur lors de la connexion.

Vous pouvez écrire des tests unitaires sur les deux conceptions, remplir les tables avec un tas de fausses données et lancer une minuterie contre la jointure par rapport à celle avec l'utilisation d'un drapeau.

0

La différence de performance dépend de la quantité de données dans ces tables. Si vous parlez de quelques centaines ou milliers de lignes utilisateur, vous ne verrez aucune différence entre les solutions. Si vous avez des millions d'utilisateurs, et peut-être une grande quantité d'accès simultané aux données, vous pouvez voir une différence.

0

Je trouverais cela étrange s'il y avait beaucoup d'un coup à la performance se joignant à ce qui sera une petite table.

Ce qui pourrait être un plus gros problème est de stocker différents types d'utilisateurs de deux manières différentes, ce qui est déroutant pour la maintenance. Je pense que votre solution est plus simple à long terme.

Questions connexes