Une colonne distincte par valeur est plus flexible en matière de recherche.
Une table clé/valeur séparée est plus flexible si différentes lignes ont différentes collections de valeurs booléennes.
Et, si
- votre liste de valeurs booléennes est plus ou moins statique
- toutes vos lignes ont toutes ces valeurs booléennes
- votre recherche critique pour les performances consiste à trouver des lignes dans lesquelles l'une des valeurs est fausse
puis utiliser des chaînes de texte comme '1001010010' etc. est un bon moyen de les stocker. Vous pouvez rechercher comme ceci
WHERE flags <> '11111111'
pour trouver les lignes dont vous avez besoin.
Vous pouvez utiliser une colonne BINARY avec un bit par indicateur. Mais votre tableau sera plus facile à utiliser pour les requêtes occasionnelles et l'inspection visuelle si vous utilisez du texte. Les économies d'espace résultant de l'utilisation de BINARY au lieu de CHAR ne seront pas significatives tant que vous n'aurez pas commencé à stocker plusieurs millions de lignes.
modifier Il faut le dire :chaque fois que j'ai construit quelque chose comme ça avec des tableaux d'attributs booléens, j'ai ensuite été déçu de voir à quel point cela s'est avéré inflexible. Par exemple, supposons qu'il s'agisse d'un catalogue d'ampoules. Au tournant du millénaire, les drapeaux booléens auraient pu ressembler à
screw base
halogen
mercury vapor
low voltage
Ensuite, les choses changent et j'ai besoin de plus de drapeaux booléens, comme,
LED
CFL
dimmable
Energy Star
etc. Tout d'un coup, mes types de données ne sont plus assez volumineux pour contenir ce dont j'ai besoin. Lorsque j'ai écrit "votre liste de valeurs booléennes est plus ou moins statique", je voulais dire que vous ne vous attendez pas raisonnablement à ce que quelque chose comme les caractéristiques de l'ampoule changent pendant la durée de vie de votre application.
Ainsi, une table d'attributs distincte pourrait être une meilleure solution. Il aurait ces colonnes :
item_id fk to item table -- pk
attribute_id attribute identifier -- pk
attribute_value
C'est finalement flexible. Vous pouvez simplement ajouter de nouveaux drapeaux. Vous pouvez les ajouter à des éléments existants ou à de nouveaux éléments à tout moment pendant la durée de vie de votre application. Et, chaque élément n'a pas besoin de la même collection de drapeaux. Vous pouvez écrire le "quels éléments ont de faux attributs ?" requête comme celle-ci :
SELECT DISTINCT item_id FROM attribute_table WHERE attribute_value = 0
Mais, vous devez être prudent car la requête "quels éléments ont des attributs manquants" est beaucoup plus difficile à écrire.
