Det beror lite på din användning. Den normaliserade metoden (park är en tabell) kommer att göra följande frågor enklare:
- Hur många fågelobservationer har det varit för varje park
- I vilken park är det mest sannolikt att du ser fågeln XYZ
- Det finns förmodligen en hel del fler sådana här frågor
Men ja, du stöter på några klibbiga problem. Mönstret "om park XYZ inte existerar, sätt in den i parkbordet" lider av ett tävlingstillstånd som du måste hantera.
Nu, vad sägs om några argument mot normalisering här... De flesta kunddatabaser lagrar förmodligen min gatuadress som "123 Foo Street", utan att dynamiskt normalisera gatunamnet (vi skulle kunna ha en gatutabell och sätta "Foo Street" där, sedan hänvisa till det från andra tabeller. Varför tar jag upp det här, för att visa att även killar som hatar upprepade uppgifter förmodligen kommer att erkänna att det finns en gräns du inte nödvändigtvis behöver gå över.
Ett annat dumt exempel skulle vara att vi kanske delar efternamn. Behöver vi verkligen en tabell för unika efternamn och sedan främmande nyckel till den från andra tabeller? Det kan finnas några applikationer där detta är till hjälp, men för 99 % av applikationerna där ute går det för långt. Det är bara mer arbete och mindre prestanda för liten eller ingen vinst.
Så jag skulle fundera på hur jag vill kunna söka data tillbaka från tabellen. Ärligt talat i det här fallet skulle jag förmodligen göra ett separat bord för parker. Men i andra fall har jag valt att inte göra det.
Det är mina två cent, en cent efter skatt.