Cela dépend un peu de votre utilisation. L'approche normalisée (parc est une table) facilitera les requêtes suivantes :
- Combien d'observations d'oiseaux y a-t-il eu pour chaque parc
- Dans quel parc êtes-vous le plus susceptible de voir l'oiseau XYZ
- Il existe probablement d'autres requêtes de ce type
Mais oui, vous rencontrez des problèmes persistants. Le modèle "si le parc XYZ n'existe pas, alors insérez-le dans la table des parcs" souffre d'une condition de concurrence avec laquelle vous devrez faire face.
Maintenant, que diriez-vous de certains arguments contre la normalisation ici... La plupart des bases de données clients stockent probablement mon adresse sous la forme "123 Foo Street", sans normaliser dynamiquement le nom de la rue (nous pourrions avoir une table de rue et y mettre "Foo Street", puis référencer à partir d'autres tables. Pourquoi est-ce que j'en parle, eh bien pour montrer que même les gars qui détestent les données répétées reconnaîtront probablement qu'il y a une ligne que vous n'avez pas nécessairement à franchir.
Un autre exemple idiot serait que nous pourrions partager des noms de famille. Avons-nous vraiment besoin d'une table pour les noms de famille uniques, puis d'une clé étrangère à partir d'autres tables ? Il peut y avoir certaines applications où cela est utile, mais pour 99 % des applications, cela va trop loin. C'est juste plus de travail et moins performant pour peu ou pas de gain.
Je considérerais donc comment je veux pouvoir interroger les données de la table. Honnêtement, dans ce cas, je ferais probablement un tableau séparé pour les parcs. Mais dans d'autres cas, j'ai choisi de ne pas le faire.
C'est mes deux cents, un cent après impôts.
