それはあなたの使用法に少し依存します。正規化されたアプローチ（パークはテーブル）により、次のクエリが簡単になります。
- 各公園で鳥の目撃情報はいくつありますか
- どの公園で鳥XYZを見る可能性が最も高いですか
- このようなクエリはおそらく他にもたくさんあります
しかし、はい、あなたはいくつかの厄介な問題に遭遇します。 「パークXYZが存在しない場合は、パークテーブルに挿入する」というパターンは、対処しなければならない競合状態に悩まされています。
さて、ここで正規化に反対するいくつかの議論はどうですか...ほとんどの顧客データベースは、通りの名前を動的に正規化せずに、おそらく私の番地を「123 FooStreet」として保存します（通りのテーブルを作成し、そこに「FooStreet」を配置して参照することができます）他のテーブルからの引用です。繰り返しのデータを嫌う人でさえ、必ずしも交差する必要のない線があることを認めるだろうことを示すために、なぜこれを取り上げるのですか。
もう1つのばかげた例は、姓を共有する場合です。一意の名前のテーブルと、他のテーブルからの外部キーが本当に必要ですか？これが役立つアプリケーションもあるかもしれませんが、99％のアプリケーションでは、これは行き過ぎです。仕事が増えてパフォーマンスが低下し、利益はほとんどまたはまったくありません。
そこで、テーブルからデータをクエリして戻す方法を検討します。正直なところ、この場合、私はおそらく公園用に別のテーブルを作成します。しかし、他の場合には、そうしないことを選択しました。
それは私の2セント、税引き後1セントです。