Zapisanie kilku wykluczających się cech na bicie w kolumnie

Hej. Jeśli mam tabelę zamówienia:
id
nazwa
właściwości

Właściwości póki co zawierają tylko jedną cechę: są albo krajowe, albo zagraniczne, co w kodzie reprezentowane jest przez bit:
zagraniczne = $01

Chciałbym zapisać też trzy wykluczające się stany: zrealizowane, niezrealizowane, anulowane. W przyszłości nie wiem czy nie będę
musiał w tej kolumnie zapisać też innych właściwości. Tak więc czy jest sposób żeby na masce bitowej zapisać nie tylko
szereg warunków tak/nie, ale też przypadki gdy są trzy warianty lub więcej?

Może czegoś nie wiem, ale w 1 bicie zmieścisz 2 informacje 0 lub 1. Teoretycznie możesz rozbić to na 2 właściwości: zrealizowane/nie zrealizowane i anulowane/nie anulowane.

Osobiście zrobiłbym osobne kolumny

co w kodzie reprezentowane jest przez bit:zagraniczne = $01

STOP. To że coś w kodzie jest reprezentowane w jakiś sposób, nie oznacza, że w bazie musisz reprezentować to w taki sam sposób. O ile to nie jest jakiś system embedded, to zrób zwykłego "enuma", i w kodzie sobie waliduj czy stan jest poprawny. Będziesz mógł potem w bazie dodawać nowe stany bez kombinowania z jakimiś bitami.

Ewentualnie tradycyjną tabelę łączącą. Ewentualnie kolumnę z enumami po przecinku nawet.

Nie napisałeś jaka baza ale w oracle (inne z pewnością też) masz możliwość stworzenia własnego typu rekordowego lub tablicowego, a nawet tablicowego rekordowego. Mając już taki swój typ z 3 polami możesz w tabeli zrobić kolumnę tego typu i po temacie. W kolejnych krokach rozbudowujesz tylko dany typ. Nie mniej jednak z tego co opisałeś dodanie kolumny tak jak zasugerował @Panczo wydaje się najsensowniejsze

Nie kombinuj z maskami, bitami itp. Po to masz bazę, żeby trzymać tam dane. Osobne pole dla każdej cechy każdemu ułatwi życie

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).

Panczo napisał(a):

Może czegoś nie wiem, ale w 1 bicie zmieścisz 2 informacje 0 lub 1.

A NULL?

@loza_prowizoryczna null możemy potraktować jako 3 wartość, ale mówimy tu o masce bitowej i dołożoniu kolejnej wartości więc jak w to upchnąć null?

Panczo napisał(a):

ale mówimy tu o masce bitowej

Maska bitowa na jednym bicie?

abrakadaber napisał(a):

Nie kombinuj z maskami, bitami itp. Po to masz bazę, żeby trzymać tam dane. Osobne pole dla każdej cechy każdemu ułatwi życie

To nie tak, że ja sobie kombinuje. Baza niby SQL, ale dorobić nowej tabeli za bardzo nie powinienem z powodu pewnych zaszłości w kodzie aplikacji. Dlatego jeśli mogę, to zapisuję właściwości w jednej kolumnie, jeśli nie, to trzeba zrobić nową.

na Twoim miejscu rozbił tę maskę bitową na osiem bitów i osiem pól w tabeli, a w nich 0 lub 1

grzegorz_so napisał(a):

na Twoim miejscu rozbił tę maskę bitową na osiem bitów i osiem pól w tabeli, a w nich 0 lub 1

W przypadku użycia ORM wprowadza to dodatkowy niepotrzebny narzut przy hydracji.

@loza_prowizoryczna

W przypadku użycia ORM wprowadza to dodatkowy niepotrzebny narzut przy hydracji.

Masz rację, ale zawsze trzeba rozważyć plusy i minusy.
Można całość danych (nie tylko te binarne) posklejać w string oddzielając jakimś separatorem i zapakować do jednego pola w tabeli. Wtedy nie będzie narzutu przy hydracji :)
Tylko czy o to chodzi ? :)

grzegorz_so napisał(a):

Można całość danych (nie tylko te binarne) posklejać w string oddzielając jakimś separatorem i zapakować do jednego pola w tabeli. Wtedy nie będzie narzutu przy hydracji :)
Tylko czy o to chodzi ? :)

To zmienia podejście z kolumnowego na szeregowe. Trzeba by rozważyć czy macierze które po transpozycji zachowują tożsamość dają jakieś dodatkowe zyski przy optymalizacji. Ale to już bardziej gratka dla matematyków, nie dla mnie.