Utilisation d'un indicateur bitwise pour une clé primaire?

Question

Je suis en train de concevoir une base de données et je pensais à la nécessité d'une relation de un à plusieurs. Traditionnellement, j'ai fait le PK normal (comme un GUID) et mis en place la relation, mais je me demandais à la place si vous faites cela, pourquoi ne pas utiliser un drapeau bitwise comme le PK.

La relation serait perdue mais les données elles-mêmes décriraient la relation.

Exemple - J'ai une table de groupes et une table d'utilisateurs. Les utilisateurs peuvent avoir 1 ou plusieurs groupes:

+------------------------+ 
| Groups     | 
+------------------------+ 
| PK  | Display Name | 
+---------+--------------+ 
| 1  | Group A  | 
| 2  | Group B  | 
| 4  | Group C  | 
+---------+--------------+ 

+------------------------+ 
| Users     | 
+------------------------+ 
| Name | Groups  | 
+---------+--------------+ 
| Fred | 1   | // Fred is only in Group A 
| Jim  | 3   | // Jim is in Groups A & B 
| Sam  | 7   | // Sam is in all Groups 
+---------+--------------+ 

Pensées, commentaires et suggestions sur ce design s'il vous plaît?

Answer 1

mauvaise idée ... comment l'index fonctionnerait-il? Il faudrait scanner et faire un calcul sur chaque valeur ...

Disons que vous vouliez connaître tous les utilisateurs du groupe X ... vous devez exécuter une fonction sur chaque ligne pour déterminer si oui ou non ils étaient dans ce groupe, plutôt que de simplement faire un index très rapide chercher votre réponse. Edit: Simplement ... écrivez-moi une requête qui utilise un index sur votre table pour trouver tous les utilisateurs du groupe B ... quoi qu'il arrive, vous ferez un calcul, ce qui le forcera à faire un retard -filtered scan

Answer 2

Bonne idée, ne voit pas comment cela pourrait être utile dans une base de données relationnelle. Je pense que si vous êtes en SQL, vous devez utiliser des clés standard, sinon quel est le point de stockage coûteux que vous avez?

Peut-être conviendrait-il mieux au stockage basé sur des fichiers où chaque table est dans un fichier différent. Ou, l'avoir comme une colonne supplémentaire, mais ne mettez pas une clé primaire sur elle.

P.S. Ne tomberait-il pas si deux utilisateurs sont dans les mêmes groupes?

Ryan

Answer 3

je déconseille l'utilisation des drapeaux de bits comme celui-ci. D'une part, vous avez cassé la possibilité de rejoindre facilement ces tables, donc déterminer l'appartenance au groupe a) prendra plus de temps, b) sera plus difficile, et c) impliquera probablement plus d'analyses de tables complètes ou au moins d'indexes.

Answer 4

Vous allez manquer de chiffres assez rapidement. Si vous avez 64 groupes, vous utilisez déjà 64 bits. Je frémis de penser à ce qui se passerait si vous aviez un million de groupes.

L'autre problème avec ceci est que, si vous supprimez un groupe, vous avez perdu un peu. Vous pouvez réutiliser ce bit plus tard, mais ce n'est peut-être pas ce que vous voulez faire.

Answer 5

Pas bon IMO. C'est une relation type plusieurs-à-plusieurs. Si PK est 32 bits, un utilisateur peut être dans 32 groupes maximum. Pourquoi limiter le design?

// Sam est présent dans tous les groupes. Supposons que vous modifiez la conception et que vous instaurez PK 4 bits de 3. Sam est-il maintenant dans "tous les groupes" ou seulement dans les groupes 0-7?

Quel est le gain?

Comment écririez-vous des requêtes (jointures)? Je pense que vous aurez des problèmes avec cette conception.

Answer 6

J'ai vu des GUID utilisés comme clés primaires récemment et je pense que c'est une idée horrible. GUID est l'abréviation de "Globally Unique ID", c'est-à-dire un identifiant dont la chance de répliquer est Brockmeyer dans son livre OLE "aussi probable qu'un tas d'atomes se précipitant ensemble dans un espace vide pour former une petite noix ".

Il existe de bonnes raisons d'utiliser les GUID si vous avez réellement besoin de quelque chose de globalement unique, mais la plupart des clés de base de données ne doivent être uniques que par rapport à la base de données en question. Dans ce cas, une clé entière générée séquentiellement est souvent suffisante et consomme beaucoup moins de ressources.En réalité, ni les ID de séquence ni les GUID n'ont de signification inhérente, il est donc préférable d'utiliser des éléments qui identifient réellement l'objet en question comme clé primaire, si vous le pouvez (bien qu'il existe une école de pensée qui dit tous les éléments devrait avoir une clé indépendante du contenu telle que séquence ou même GUID).

Les champs de bits ont plusieurs responsabilités en tant que clés primaires. Comme cela a été mentionné, vous pouvez décider que vous avez besoin de bits supplémentaires. Vous pourriez vous retrouver avec des collisions. Les bases de données ont tendance à être pauvres en fonctionnalités bitwise et non portables même alors. Et enfin, les algorithmes d'indexation pour votre base de données de choix peuvent ne pas être capables d'optimiser les clés bitset bien.