Osobiście nie szedłbym w reprezentacje bitowe bez jakiegoś bardzo dobrego powodu.
Wiele wykluczających się cech -> kolumna z szerszym niż (bit) typem (np. number) + słownik do niej (osobna tabela).
Na upartego w ten sposób możesz w słowniku definiować kombinacje bitowe i przypisywać im jakiś klucz i opis zrozumiały dla człowieka. To umożliwi wykonanie zapytań bezpośrednio na bazie (bo kto będzie wiedział, czy ma zrobić w zapytaniu BIT18&wartość czy może BIT27&wartość). Do tego masz kontrolę poprawności na poziomie bazy (nie zapiszesz jakiejś dziwnej/niedozwolonej kombinacji) - klucz obcy do słownika nie pozwoli.
Przy wielu cechach, to pewnie zależy ile ich jest i jaką mają naturę (statyczną, dynamiczną) , np.
a) mało -> osobne kolumny
b) bardzo dużo -> tabela łącząca (id obiektu, id cechy, wartość cechy)
statyczne - pewnie CHECK wystarczy
dynamiczne - CHECK nie wystarczy, słownik
Przy operacjach bitowych na dużej ilości danych (wyszukiwanie opcji z zapalonym bitem) zapewne przydadzą Ci się indeksy funkcyjne. Łatwiej zrobić wyszukiwanie zapalonego bitu w słowniku (mniej danych), niż zapalonego bitu w zamówieniach (dużo danych).