あなたが完全に説明することができれば、または方向性を教えていただければ幸いです.
ビジネスを保存するDBを作成し、それらを地域周辺で行うアクティビティとしてリストしようとしています。階層形式では、次のように保存します。
活動カテゴリ
アクティビティ
アクティビティのカテゴリは次のとおりです: インドア、アウトドア、アートなど
アクティビティのサブカテゴリは次のとおりです: 水族館、博物館、公園など
アクティビティがサブカテゴリのリストになる場所: フロリダ水族館、大英博物館..
上記の 3 つの名前をテーブルとして使用したとします。適切な関係は何でしょうか? ActivitySubCategory テーブルで、ActivityCategoryID Pk との関係を持つ FK を作成しますか? ActivitySubCategoryID PK に関連する Activity テーブルに FK を作成しますか?
多対多の関係になる可能性が高いため (たとえば、芸術には多くのサブカテゴリがありますが、大英博物館は芸術と屋内にある可能性があります)、結合テーブルまたはリンク テーブルを追加する必要があります。アクティビティ テーブルとサブアクティビティ テーブルの両方からの ids 値。必ず両方を PK として使用して、各コンボを 1 回しか入力できないようにしてください。
各アクティビティには、カテゴリが 1 つだけありますか? 私の提案は、Activity テーブルを作成してから、ParentCategory 列を持つ Category テーブルを作成することです。これは自己参照結合になります。
アクティビティがカテゴリを 1 つだけ持つことができる場合、必要なのは単純な FK リレーションシップだけです。そうでない場合は、連想として 3 番目のテーブルが必要になります。
あなたが提案したように、外部キーを作成できます：
ただし、これによりアクティビティが 1 つのサブカテゴリのみに制限されます。アクティビティを複数のサブカテゴリに関連付ける必要がある場合は、アクティビティとアクティビティサブカテゴリの両方への外部キーを持つルックアップ テーブルを作成する必要があります。
カテゴリの可能なレベルをさらに想定する場合は、それ自体への FK を持つ単一の ActivityCategories テーブルを作成できます。これは、同じテーブルの行間の親子関係になるため、ActivityCategories.PK を参照する ActivityCategories.ParentKey を作成することをお勧めします。最上位の ActivityCategory には、NULL の ParentKey があります。
さらに、外部キーにインデックスを作成することをお勧めします。たとえば、Activity.ActivitySubCategoryKey と ActivitySubCategory.ActivityCategoryKey のインデックスを作成します。これを行わないと、アクティビティ カテゴリまたはサブカテゴリの削除に非常に長い時間がかかる可能性があります。
他の回答を拡張し、この種の問題に私がどのようにアプローチしているかについての洞察を提供します。
データベース構造は、私が最後に考えるものです。結局のところ、RDMS はデータ ストアであり、使用していないときにデータが保管される場所です。
モデル化している現実世界の問題について考えるところから始めます。実世界のオブジェクトは、ソフトウェア オブジェクトとしてモデル化されます。どのプロパティが不可欠であり、それらのオブジェクトを進化させるにはどのようなメソッドが必要ですか。この構造を明確にすると、データベース スキーマは自然に脱落します。
あなたの問題には、2つの実世界のものがあります。活動とカテゴリー。それらの固有のプロパティを無視して、これらのオブジェクトがどのように相互作用するかを検討してください。
アクティビティ
カテゴリー