データベース設計：ネストされたオブジェクトには独自のテーブルが必要ですか？

Question

私はデータベース設計に若干新しかったので、現在のテーブルをどのように最適にレイアウトするかについてのいくつかの指針を示したいと思います。

私はさまざまな仕事を保持するテーブルJobsを持っています。ユーザーはSubjobsを作成できます。 Subjobは、親としてJobを有する。 SubjobはすべてJobと同じプロパティを持ちますが、一部は読み取り専用ですが、すべてJobの読み取り/書き込みです。 Jobは、多くの場合、Subjobsを持つことができます。現時点では、1つのサブジョブ層しか存在しないかもしれませんが、将来はSubjobsという無限のネストを可能にする柔軟性が欲しいと思います。オブジェクトは、MVC Webアプリケーションを介して対話されます。

私は、レイアウトのための2つの選択肢と考えられてきました：

• JobsとSubjobsそれぞれ独自のテーブルを持っています。
  • Jobに列を導入していないため、これは「良いデザイン」のように思えます。
  • JobとSubjobは、プロパティが同じでも、2つの別々のコントローラ/ビューセットを持つ必要があるため、Webアプリケーションのコーディングには少し苦労します。
  • 無限のネストが導入されていると、設計の観点からはあまり意味がありません。
• JobsとSubjobsは同じテーブルにあります。 Jobsは、Subjobの場合はnull以外のnull可能なparent_job_idプロパティが与えられているだけです。
  • 無限のネスティングに適しています。
  • ウェブアプリケーションをコーディングするための苦痛が少なくなります。
  • Jobの実際のプロパティとは関係のないJobテーブルに、奇妙なネスティングプロパティが導入されています。

これを処理する方法についてのアドバイスはありますか？私が考慮していない追加のデザインパターンはありますか？私がEntity Framework 6 Code Firstを使用しています。

Answer 1

複数のレベルで階層を記述していなくても、最初のオプションは問題ありません。あなたが記述しているパターンは、一般に隣接リストとして知られています。これは、2番目のオプションを記述するときに格納されます。

階層を格納するための他のいくつかのオプションは次のとおりです。

• ネストされたセット（より複雑な実装が、再帰のない潜在的に速くクエリ）。
• マテリアライズドパス（階層パスの文字表現を格納します。ファイルストレージシステムなど）
• 変更/隣接リストのヘルパーテーブル（フラットテーブル、ブリッジテーブル）HierarchyId

階層リファレンスのよう

カスタム実装：

• StackOverflow - What are the options for storing hierarchical data in a relational-database
• Louis Davidson - Presentations - How to Optimize a Hierarchy In SQL Server - Presentations & Demo Code