Зависи малко от вашата употреба. Нормализираният подход (park е таблица) ще улесни следните заявки:
- Колко наблюдения на птици е имало за всеки парк
- В кой парк е най-вероятно да видите птица XYZ
- Вероятно има още доста запитвания като това
Но да, срещате някои лепкави проблеми. Моделът „ако паркът XYZ не съществува, тогава го вмъкнете в таблицата с паркове“ страда от състояние на състезание, с което ще трябва да се справите.
Сега, какво ще кажете за някои аргументи срещу нормализирането тук... Повечето клиентски бази данни вероятно съхраняват моя уличен адрес като „123 Foo Street“, без динамично нормализиране на името на улицата (можем да имаме таблица с улици и да поставим „Foo Street“ там, след което да препращаме от други таблици. Защо повдигам това, добре, за да покажа, че дори момчетата, които мразят всякакви повтарящи се данни, вероятно ще признаят, че има някаква линия, която не е задължително да пресичате.
Друг глупав пример би бил, че можем да споделяме фамилии. Наистина ли имаме нужда от таблица за уникални фамилни имена и след това външен ключ към нея от други таблици? Може да има някои приложения, при които това е полезно, но за 99% от приложенията там това отива твърде далеч. Това е просто повече работа и по-малко производителност за малка или никаква печалба.
Така че бих помислил как искам да мога да заявя данни обратно от таблицата. Честно казано в този случай вероятно бих направил отделна маса за паркове. Но в други случаи съм избрал да не го правя.
Това са моите два цента, един цент след данъци.
