データベースの設計-カテゴリとサブカテゴリ
ゴールデンページに少し似ているものに分類とサブ分類を実装する必要があります。
次の表があるとします。
カテゴリテーブル
CategoryId, Title
10, Home
20, Business
30, Hobbies
サブカテゴリをコード化する方法は2つあります。
オプション1-サブカテゴリIDはカテゴリ内でのみ一意です：
サブカテゴリー表
CategoryId, SubCategoryId, Title
10, 100, Gardening
10, 110, Kitchen
10, 120, ...
20, 100, Development
20, 110, Marketing
20, 120, ...
30, 100, Soccer
30, 110, Reading
30, 120, ...
オプション2-サブカテゴリIDは全体的に一意です：
サブカテゴリー表
CategoryId, SubCategoryId, Title
10, 100, Gardening
10, 110, Kitchen
10, 120, ...
20, 130, Development
20, 140, Marketing
20, 150, ...
30, 160, Soccer
30, 170, Reading
30, 180, ...
オプション2は、テーブルから行をフェッチする方が簡単であるように思われます。次に例を示します。SELECT BizTitle FROM tblBiz WHERE SubCatId = 170
一方、オプション1を使用する場合は、次のように記述する必要があります。
SELECT BizTitle FROM tblBiz WHERE CatId = 30 AND SubCatId = 170
つまり、追加のANDが含まれています
ただし、オプション1は手動で保守する方が簡単です（新しいサブカテゴリを更新して挿入する必要がある場合など）、私の意見ではより快適です。
それについて何か考えはありますか？オプション2は効率の面で問題の価値がありますか？この一般的な問題に関連する設計パターンはありますか？
私はこの構造を使用します：
ParentId, CategoryId, Title
null, 1, Home
null, 2, Business
null, 3, Hobbies
1, 4, Gardening
1, 5, Kitchen
1, 6, ...
2, 7, Development
2, 8, Marketing
2, 9, ...
3, 10, Soccer
3, 11, Reading
3, 12, ...
詳細に：
- それ自体を参照するである1つのテーブルのみを使用して、カテゴリの深さを無制限にすることができます
- technical ids（
IDENTITYまたは類似のものを使用）を使用して、10を超えるサブカテゴリを作成できるようにする - 必要に応じて、カテゴリ番号の人間が読める形式列を別のフィールドとして追加します
2レベルのカテゴリのみを使用している限り、次のように選択できます。
SELECT BizTitle FROM tblBiz WHERE ParentId = 3 AND CategoryId = 11
SQLサーバーの新しいhierarchyid機能も非常に有望に見えます： https://msdn.Microsoft.com/en-us/library/bb677173.aspx
ネストされたセットモデルについて私が気に入らない点：
- 挿入と削除Nested Set Modelの項目は非常に複雑で、高価なロックが必要です。
parentフィールドを外部キー制約と組み合わせて使用すると、禁止されているinconsistenciesを簡単に作成できます。rghtがlowerlftの場合、不整合が発生する可能性があります- 値apprears in multiple
rghtまたはlftフィールドの場合、不整合が発生する可能性があります - gapsを作成すると、不整合が発生する可能性があります
- overlapsを作成すると、矛盾が発生する可能性があります
- 入れ子集合モデルは私の意見ではより複雑であり、したがって理解するのは簡単ではありません。もちろん、これは完全に主観的です。
- Nested Set Modelは、1つではなく2つのフィールドを必要とするため、より多くのディスク領域を使用します。
オプション1を使用することをお勧めします-サブカテゴリをカテゴリ内で一意にします。関連のないアイテムの2つのカテゴリがあるとします。
- 果物
- 色
それぞれにサブカテゴリが必要です
果物
- Apple
- オレンジ
色
- 白い
- オレンジ
Orangeは各カテゴリ内のサブカテゴリです。名前は同じですが、機能が大きく異なります。 （オレンジ色の果物がオレンジ色である可能性を考えてみましょう）
このデザインでは、誰かが気が変わってオレンジの名前をオレンジに変更したい場合は、問題ありません。色の下のオレンジ色のサブカテゴリに影響を与えずに変更するのは簡単です。
マーケティングが色のサブカテゴリを制御できるようにUIが構築されているのに対し、プロダクションは果物のサブカテゴリを制御できる場合、この設計により、マーケティングはプロダクションのサブカテゴリをまたぐことなく、サブカテゴリを操作できます。