Rozważ następujące tabele:

CREATE TABLE user_roles(
    pkey         SERIAL PRIMARY KEY,
    bit_id       BIGINT NOT NULL,
    name         VARCHAR(256) NOT NULL,
);

INSERT INTO user_roles (bit_id,name) VALUES (1,'public');
INSERT INTO user_roles (bit_id,name) VALUES (2,'restricted');
INSERT INTO user_roles (bit_id,name) VALUES (4,'confidential');
INSERT INTO user_roles (bit_id,name) VALUES (8,'secret');

CREATE TABLE news(
    pkey          SERIAL PRIMARY KEY,
    title         VARCHAR(256),
    company_fk    INTEGER REFERENCES compaines(pkey), -- updated since asking the question
    body          VARCHAR(512),
    read_roles    BIGINT -- bit flag 
);

read_roles to flagi bitowe, które określają pewną kombinację ról, które mogą odczytywać wiadomości. Więc jeśli wstawiam wiadomość, która może być odczytana przez zastrzeżoną i poufną, ustawiłbym read_roles na wartość2 | 4 lub 6 i kiedy chcę odzyskać wiadomości, które dany użytkownik może zobaczyć, mogę użyć zapytania takiego jak.

select * from news WHERE company_fk=2 AND (read_roles | 2 != 0) OR  (read_roles | 4 != 0) ; 
select * from news WHERE company_fk=2 AND read_roles = 6; 

Jakie są wady używania flag bitów w kolumnach baz danych w ogóle? Zakładam, że odpowiedź na to pytanie może być specyficzna dla bazy danych, więc jestem zainteresowany poznaniem wad konkretnych baz danych.

Używam Postgres 9.1 dla mojej aplikacji.

AKTUALIZACJA Mam trochę informacji o tym, że baza danych nie używa indeksu dla operacji bitowych, które wymagałyby pełnego skanowania tabeli, co mogłoby zaspokoić wydajność. Zaktualizowałem więc pytanie, aby dokładniej odzwierciedlić moją sytuację, każdy wiersz w bazie danych należy do konkretnej firmy, więc wszystkie zapytania będą miały klauzulę WHERE, która będzie zawierać company_fk, która będzie miała na niej indeks.

AKTUALIZACJA Mam teraz tylko 6 ról, możliwe, że w przyszłości.

AKTUALIZACJA role nie wykluczają się wzajemnie i dziedziczą po sobie, na przykład ograniczone dziedziczą wszystkie uprawnienia nadane publicznie.