Dipende un po' dal tuo utilizzo. L'approccio normalizzato (park è una tabella) semplificherà le seguenti query:
- Quanti uccelli ci sono stati per ogni parco
- In quale parco è più probabile vedere l'uccello XYZ
- Probabilmente ci sono altre domande come questa
Ma sì, ti imbatti in alcuni problemi appiccicosi. Lo schema "se il parco XYZ non esiste, inseriscilo nella tabella dei parchi" soffre di una condizione di gara che dovrai affrontare.
Ora, che ne dici di alcuni argomenti contro la normalizzazione qui... La maggior parte dei database dei clienti probabilmente memorizza il mio indirizzo come "123 Foo Street", senza normalizzare dinamicamente il nome della strada (potremmo avere una tabella delle strade e inserire lì "Foo Street", quindi fare riferimento da altre tabelle. Perché ne parlo, anche per mostrare che anche i ragazzi che odiano i dati ripetuti probabilmente riconosceranno che c'è una linea che non devi necessariamente attraversare.
Un altro esempio sciocco potrebbe essere che potremmo condividere i cognomi. Abbiamo davvero bisogno di una tabella per cognomi univoci e quindi di una chiave esterna da altre tabelle? Potrebbero esserci alcune applicazioni in cui ciò è utile, ma per il 99% delle applicazioni disponibili, questo va troppo oltre. È solo più lavoro e meno prestazioni per un guadagno minimo o nullo.
Quindi prenderei in considerazione come voglio essere in grado di interrogare i dati fuori dalla tabella. Onestamente in questo caso farei probabilmente una tabella separata per i parchi. Ma in altri casi ho scelto di non farlo.
Sono i miei due centesimi, un centesimo al netto delle tasse.
