projektowanie bazy danych - null czy osobna tabela?

Question

Witam, chciałbym się dowiedzieć, która z podanych niżej opcji jest bliższa idealnemu projektowi bazy danych.. a może jest coś innego co nie przyszło mi do głowy?

Dla jak najjaśniejszego przedstawienia problemu posłużę się przykładem.

Wyobraźmy sobie, że tworzymy jakąś grę i tworzymy bazę danych dostępnych w niej jednostek.

Jednostki mogą, ale nie muszą, posiadać statystykę "atak". Dla przykładu należy podkreślić, że atak = 0, obraz brak ataku ( null ) to dwie różne wartości w naszej grze. Przykładowo, jednostka o wartości ataku 0 może dostać jakiegoś tymczasowego buffa od innej jednostki, ale jednostka z wartością ataku null takiego buffa dostać nie może.

Sedno pytania - czy projektując bazę danych przechowującą listę wszystkich jednostek lepiej jest zrobić dla każdej jednostki kolumnę o nazwie "atak", wtedy tabela mogłaby wyglądać tak: Jednostki[id, name, atak] a kolumna atak mogłaby przyjąć inta lub nulla.

Czy może lepiej jest zrobić osobną tabelę w relacji jeden do jeden przechowującą dane o ataku dla jednostek, które ten atak posiadają. Wtedy wyglądałoby to tak: Jednostki[id, name]   Atak[jednostka_id, wartość]

Z góry dziękuję za rozwianie moich wątpliwości (:

Answer 1

Generalnie to o czym piszesz jest rozwiązane w wielu ORMach. W doctrine nazwali to Discriminator i umożliwia ustrukturyzowanie obiektów aplikacji na bazie danych. Wygląda to następująco:

1. Single table - rozwiązaniem są pola typu null. Zaleta jest tak że wszystko trzymane jest w jednej tabeli. Wad jest o wiele więcej: różnice zawarte między poszczególnymi obiektami muszą być niewielkie, gdyż tabela ma tyle kolumn ile jest łącznie wszystkich pól. Kolejny problem jest taki iż to rozwiązanie jest całkiem mocno zamknięte na zmiany. Potem trzeba walczyć z migracją danych jeśli poszczególne typy zaczną się bardziej różnić. Ostatni problem jaki dostrzegam to fakt, iż kolumny nullable ważą więcej. Ma to znaczenie dla nieco większej skali, ale dobrym zwyczajem jest branie tego pod uwagę.
2. Join table - mamy jedną tabelę dla klasy bazowej trzymająca wszystkie pola wspólne jednostek. Ogólnie polecam całkiem spoko rozwiązanie. Problem jaki może się tutaj pojawić to oddzielna tabela per typ. Przy bardziej rozbudowanych systemach 100 typów to 100 oddzielnych tabel. potem z poziomu samej bazy ciężko to agregować.
3. Wykorzystanie jsona. Zarówno mysql oraz postgres wspierają typ json. Pola uniwersalne dla jednostek możesz trzymać w kolumnach, dane specyficzne w jednej kolumnie z jsonem. Połowiczna otwartość na zmiany: mogą być problemy z ewentualną migracją danych, ale bardziej przykry jest fakt iż cały czas musisz w swojej aplikacji zapewniać obsługę dla każdego rodzaju schemy takiego jsona. 

 Jest jeszcze jedna kwestia. Czy jeśli mam 200 jednostek takiego samego typu to atak każdej będzie inny? Może nie i wtedy nie warto robić kolumn, tylko trzymać to w constach po stronie aplikacji albo w innej tabeli, w pojedynczym rekordzie. ​​​​​​

Niestety odpowiedź na tego typu pytania zawsze brzmi zależy. Przeanalizuj to co opisałem i dobierz dobre rozwiązanie.

Comments

Dziękuję za odpowiedź. Muszę przyznać, że dało mi to dużo szerszy obraz na sytuację niż oczekiwałem c;

---

Dobrze że mogłem pomóc. Nie wiem w jakim języku piszesz, czy może zajmujesz się tylko db, ale warto tutaj korzystać z gotowych ORMów i bibliotek które dużo rzeczy automatyzują. Z drugiej strony warto dobierać rozwiązania przyszłościowe patrząc poza tym co dostarczają biblioteki