Meilleure façon de stocker beaucoup de colonnes booléennes dans le tableau

Question

Je ne suis pas sûr si ce genre de question a déjà été posée mais j'ai cherché et j'ai pu trouver n'importe quoi.

Je travaille sur une base de données au moment où a des dossiers qui ont beaucoup de valeurs à base de booléennes stockées avec eux, de sorte que la structure de la table ressemble à quelque chose comme ceci:

===Table=== 
ID <- int 
Name <- string 
Bool1 <- bool 
Bool2 <- bool 
Bool3 <- bool 
Bool4 <- bool 
Bool5 <- bool 
Bool6 <- bool 
Bool7 <- bool 
Bool8 <- bool 
Bool9 <- bool 

pas toutes les valeurs booléennes sont définies une fois, de sorte que chaque enregistrement peut avoir un, plusieurs ou aucun sélectionné.

J'ai pensé à faire quelque chose comme ceci:

==Main Table==  ===Second Table==== 
ID <- int PK   ValueID <- PK links to Main Table ValueID 
Name <- string  ID <- int 
ValueID <- FK   Value <- Contains name of assigned value eg Bool1, Bool2 

Donc, il y a une relation un à plusieurs entre la table principale et deuxième table jointe sur ValueID. Ainsi, la seconde table n'a que les données pour les éléments sélectionnés et plutôt un tas de valeurs booléennes vides dans la table principale.

La raison pour laquelle je pensais à le faire de cette façon était-il me permettrait d'ajouter différentes valeurs à stocker sur le disque à l'avenir plutôt puis en changeant la structure de la table.

Serait-ce un bon moyen de stocker les valeurs booléennes?

Je voudrais vraiment être en mesure de lier cela à une forme avec des cases à cocher , irait de cette façon rendre difficile. Donc, si c'est un peu difficile à comprendre ce dont j'ai besoin, je ne sais pas vraiment comment l'expliquer dans le texte.

Merci.

Answer 1

Juste une idée, vous pouvez utiliser int pour stocker des bits, le fonctionnement au niveau du bit sont efficaces, mais je ne suis pas sûr de savoir comment SQL les supporte. En C# il y a Bit Enums, donc vous pouvez enregistrer sa valeur directement.

Answer 2

Si vous vous attendez à ce que le nombre de booléens pour un enregistrement principal change, je vous recommande d'opter pour la séparation en deux tables.

Ne placez pas le FK (ValueID) dans la table principale, mais placez le MainID dans la deuxième table à la place.

Certaines choses qui ne sont pas claires de votre question: Si une valeur est pas définie, est-ce équivalent à une valeur fausse ou avez-vous la logique ternaire avec des valeurs nulles? Si c'est le cas, vous devrez placer un champ booléen dans votre deuxième table. Sinon, l'absence d'un enregistrement dans la seconde table est suffisante pour donner la fausse logique.

Si le nombre d'attributs booléens ne change pas, vous pouvez les mettre dans un seul champ entier et les masquer comme le suggère Mike Chaliy.

Answer 3

Laissez-le tel quel!

La base de données va emballer plusieurs champs de bits très efficacement. J'ai vu des gens faire des choses comme avoir un champ int 32 bits, leur permettant ainsi de stocker leurs 17 valeurs booléennes à l'aide de bitmasking et de 'laisser de la place pour des champs supplémentaires'. C'est tout simplement bête, c'est un cauchemar de maintenance et vos requêtes deviennent jonchées de bitmasks, ce qui les rend difficiles à maintenir.

Je vais réitérer, garder les choses simples, il suffit d'avoir les colonnes booléennes. Si vous avez besoin d'une nouvelle colonne, ajoutez-la. Vous n'avez pas besoin de créer une table séparée.