To zależy trochę od twojego użytkowania. Znormalizowane podejście (park to stół) ułatwi następujące zapytania:
- Ile zaobserwowano ptaków w każdym parku
- W którym parku najprawdopodobniej zobaczysz ptaka XYZ
- Prawdopodobnie jest więcej takich zapytań
Ale tak, napotykasz kilka lepkich problemów. Wzorzec „jeśli park XYZ nie istnieje, wstaw go do tabeli parków” cierpi na sytuację wyścigu, z którą będziesz musiał sobie poradzić.
A co powiesz na kilka argumentów przeciwko normalizacji tutaj... Większość baz danych klientów prawdopodobnie przechowuje mój adres ulicy jako „123 Foo Street”, bez dynamicznej normalizacji nazwy ulicy (możemy mieć tabelę ulic i umieścić tam „Foo Street”, a następnie odwołać się do z innych tabel. Dlaczego o tym wspominam? Cóż, żeby pokazać, że nawet ci, którzy nienawidzą powtarzających się danych, prawdopodobnie przyznają, że jest pewna granica, której niekoniecznie musisz przekraczać.
Innym głupim przykładem może być to, że możemy dzielić się nazwiskami. Czy naprawdę potrzebujemy tabeli dla unikalnych nazwisk, a następnie klucza obcego do niej z innych tabel? Mogą istnieć pewne aplikacje, w których jest to pomocne, ale w przypadku 99% aplikacji jest to za daleko. To po prostu więcej pracy i mniej wydajności przy niewielkim lub zerowym zysku.
Zastanowiłbym się więc, jak chcę mieć możliwość wysyłania zapytań do danych z powrotem z tabeli. Szczerze mówiąc w tym przypadku prawdopodobnie zrobiłbym osobny stolik dla parków. Ale w innych przypadkach zdecydowałem się tego nie robić.
To moje dwa centy, jeden cent po opodatkowaniu.
