Es hängt ein bisschen von Ihrer Nutzung ab. Der normalisierte Ansatz (Park ist eine Tabelle) erleichtert die folgenden Abfragen:
- Wie viele Vogelbeobachtungen gab es in jedem Park
- In welchem Park sehen Sie am ehesten Vogel XYZ
- Wahrscheinlich gibt es noch einige weitere Suchanfragen dieser Art
Aber ja, Sie stoßen auf einige klebrige Probleme. Das Muster "Wenn Park XYZ nicht existiert, dann füge ihn in die Parks-Tabelle ein" leidet unter einer Race-Condition, mit der Sie fertig werden müssen.
Nun, wie wäre es hier mit einigen Argumenten gegen die Normalisierung ... Die meisten Kundendatenbanken speichern meine Adresse wahrscheinlich als "123 Foo Street", ohne den Straßennamen dynamisch zu normalisieren (wir könnten eine Straßentabelle haben und dort "Foo Street" einfügen, dann Referenz aus anderen Tabellen. Warum erwähne ich das, um zu zeigen, dass selbst die Typen, die wiederholte Daten hassen, wahrscheinlich anerkennen werden, dass es eine Grenze gibt, die Sie nicht unbedingt überschreiten müssen.
Ein weiteres dummes Beispiel wäre, dass wir Nachnamen teilen könnten. Brauchen wir wirklich eine Tabelle für eindeutige Nachnamen und dann einen Fremdschlüssel aus anderen Tabellen? Es mag einige Anwendungen geben, bei denen dies hilfreich ist, aber für 99 % der Anwendungen da draußen geht dies zu weit. Es ist nur mehr Arbeit und weniger Leistung für wenig bis gar keinen Gewinn.
Also würde ich überlegen, wie ich in der Lage sein möchte, Daten aus der Tabelle abzufragen. Ehrlich gesagt würde ich in diesem Fall wahrscheinlich eine separate Tabelle für Parks erstellen. Aber in anderen Fällen habe ich mich dagegen entschieden.
Das sind meine zwei Cent, ein Cent nach Steuern.
