Nie tak dawno temu rozmawiałem z moim kolegą i zdecydowanie był przeciwny stosowaniu masek bitowych, ponieważ trudno jest zrozumieć wszystkie wartości przechowywane w bazie danych. Moim zdaniem korzystanie z nich nie zawsze jest złym pomysłem, na przykład w celu określenia ról bieżącego użytkownika. W przeciwnym razie musisz przechowywać go w osobnej tabeli, co spowoduje jeszcze jeden DOŁĄCZ. Czy możesz mi powiedzieć, jeśli się mylę? Jakieś inne skutki uboczne, zalety / wady stosowania masek bitowych?
database
patterns-and-practices
bit
advantages
Alex Ovechkin
źródło
źródło
Odpowiedzi:
Pracuję z aplikacją, która wykorzystuje maski bitowe do przechowywania przypisań ról użytkownika. To jest ból w tyłku. Jeśli to sprawia, że jestem stronniczy, winny, jak oskarżony.
Jeśli korzystasz już z relacyjnej bazy danych, jest to anty-wzorzec, który narusza większość teorii relacyjnych i wszystkie reguły normalizacji. Kiedy budujesz własny magazyn danych, może to nie być taki zły pomysł.
Jest coś takiego, że łączy się zbyt wiele tabel, ale do tego służą zbudowane relacyjne bazy danych. Wiele z nich ma dodatkowe funkcje, jeśli wydajność staje się problemem: indeksy, widoki indeksowane itp. Nawet jeśli wartości, na które patrzysz, nie zmieniają się zbyt często, co jest zaletą dla maski bitowej, narzut związany z zarządzaniem indeksowaniem jest dość łatwe w bazie danych.
Chociaż baza danych dobrze agreguje dane, mogą stać się powolne, gdy zaczniesz wprowadzać takie rzeczy, jak złożone formuły lub funkcje skalarne do zestawów danych. Możesz zrobić to bitowo w swojej aplikacji, ale jeśli wszystko, co robisz, to uzyskiwanie powiązanych danych (wyszukiwanie ról użytkownika), nie korzystasz z tego, co najlepiej robi twoje przechowywanie danych.
Moim ostatnim argumentem przeciwko temu byłaby prostota dla innych programistów. Masz użytkowników, role i zadania. Jest to zestaw relacji wiele do wielu (ponieważ istnieje więcej niż jeden związek), który jest tak powszechny, że zarządzanie nim powinno być łatwe. To tylko CRUD.
źródło
where some_bit_mask & 12 > 0bez skanowania wiersz po wierszu.user_role_maplubuser_priv_mapstole by wystarczyło.Wymieniłeś już odpowiednie zalety i wady:
Podjęcie decyzji co zrobić wymaga więcej informacji:
Musisz więc zebrać czynniki ryzyka, a następnie zważyć je, aby sprawdzić, czy zalety przewyższają wady.
źródło
Jeśli jesteś naprawdę, naprawdę , naprawdę przywiązany do miejsca na dysku, to może rozważyć bitmap dla uprawnień użytkownika. Jeśli martwisz się wydajnością, zapomnij o nich całkowicie, ponieważ ich rozdzielanie będzie w rzeczywistości wolniejsze. Nie można w sposób znaczący indeksować pola bitmapowego, co powoduje skanowanie tabel bazy danych, które [prawie] zawsze są zabójcami wydajności.
O ile nie jesteś Amazonem ani Netflixem, ilość danych związanych z uprawnieniami użytkownika będzie znikoma w porównaniu do wszystkiego, co przechowujesz.
Każdy poważny DBMS może poradzić sobie z tym „dodatkowym złączeniem” nawet bez mrugnięcia okiem.
źródło
Kiedy magazynowanie było drogie, dobrodziejstwem mask bitowych było to, że oszczędzali miejsce. W czasach dużych zbiorów danych nie był to kiedyś problem.
Biorąc przykład, który przytaczasz - posiadanie ról zapisanych jako maska bitowa byłoby czymś w rodzaju zapachu kodu z punktu widzenia projektu bazy danych, ponieważ naruszałoby to pierwszą normalną formę . W tym sensie są anty-wzorem.
Biorąc to wszystko pod uwagę, nie musi to być jedno lub drugie. Możesz przechowywać dane jako maskę bitową, a następnie mieć widok, który może błyskawicznie pobierać role użytkownika. Będziesz wtedy miał również możliwość szybkiego sprawdzenia, którzy użytkownicy mieli te same role.
źródło
Jedyną zaletą korzystania z maski bitowej jest to, że znaczenie pól bitowych nie jest statyczne. Tabele relacyjne działają dobrze tylko wtedy, gdy wiesz z góry, co każde pole jest w rekordzie: w końcu musisz zidentyfikować pola w instrukcji
CREATE TABLEDDL.Jeśli znaczenie każdego pola bitowego jest konfigurowalne w czasie wykonywania lub w inny sposób nie jest znane z wyprzedzeniem, warto zapisać wartości logiczne jako pole bitowe. Nawet wtedy, możliwe jest zdefiniowanie tabeli z dowolnych pól:
field_1,field_2, itd. To daje czystsze relacyjnych, choć nadal nie jest idealny. To, czy jest to preferencyjne dla pola bitowego, jest w dużej mierze kwestią opinii, ponieważ żadne z tych rozwiązań nie jest idealne.Jeśli wiesz, co bity reprezentują podczas programowania, utwórz pola dla każdego bitu i nadaj im sensowne nazwy .
Uważaj tylko na efekt wewnętrznej platformy . Jeśli skończysz definiować dowolne, ale dobrze wpisane pola, to jedno, ale jeśli pójdziesz o wiele dalej, odkryjesz relacyjną bazę danych ... wewnątrz relacyjnej bazy danych.
źródło
Jestem ambiwalentny co do masek bitowych. Uważam, że większość ich krytyków nie rozumie wartości binarnych i szesnastkowych. Dla jasności używaj dobrych mnemoników.
Zaletą niewymienioną powyżej jest możliwość dodawania nowego znaczenia do masek bitowych bez potencjalnie czasochłonnego dodawania nowej kolumny. Nasi projektanci db (którzy mnie poprzedzili) mają je w tabeli, która codziennie otrzymuje 5 milionów nowych rekordów. Dodanie nowej kolumny reprezentującej nowe zachowanie zajęłoby dużo czasu, podczas gdy zdefiniowanie nowego bitu (zużyliśmy 33 z 64) nie wymaga przebudowy tabeli.
Nie, maski bitowe nie mogą być indeksowane, ale budowanie 33 indeksów byłoby śmieszne i spowalniałoby wstawianie do indeksowania. Wyszukiwania w tabelach wykorzystują indeksy dat i rekordów „właścicieli”, dlatego indeksy tej maski bitowej, jeśli to możliwe, nigdy nie byłyby używane.
źródło
Jeśli celem jest jedynie oszczędność miejsca na dysku, myślę, że to zły pomysł:
Istnieją jednak przypadki, w których użycie pól bitowych może być uzasadnione:
źródło