在庫管理システムのEAV構造を作成しようとしていました。しかし、私は この答え を読み、それに対して反対しました。すべての製品に対して複数のテーブルを作成したいと考えています。しかし、今問題となっているのは、すべての製品にカテゴリーとサブカテゴリー(2層のみ)があることです。製品のカテゴリを反映するテーブルを作成するにはどうすればよいですか。カテゴリとサブカテゴリごとにテーブルを作成しますか?カテゴリーとサブカテゴリーは検索可能である必要があります。
たとえば、product table
Product:
str:name
str:description
バッテリーの情報を含むバッターテーブル
Battery:
str:volt
str:size
fr:product_id
Doll:
str:material
str:stuffing
fr:product_id
しかし、人形とバッテリーに独自のカテゴリとサブカテゴリがある場合、どのようにケースを処理しますか?サブカテゴリとサブカテゴリは、製品を追加するときに特定の製品に関連している必要もあります。
doll_categories
、doll_sub_categories
、battery_categories
、battery_categories
を作成しますか?商品を追加していくような気がします。すべての製品には3つのテーブルが必要ですが、テーブルの数が増える可能性があります。
この状況を処理する最良の方法は何ですか?
まず最初に、製品タイプごとに1つのテーブルを選択することに同意するかどうかはわかりません。私はそれが間違っているとは言っていませんが...それはあなたに道を行く悲しみの多くを引き起こす可能性があります。それは壊れやすいスキーマです。あなたはよく知っています。少し休んで、もう少し考えてみてください。
カテゴリ->サブカテゴリに関して、最も簡単な攻撃計画は、おそらく製品をリンクする関係テーブルを持つ2つのテーブルです。あなたの慣習を使う:
Category:
int: id
str: name
SubCategory:
int: id
str: name
fk: Category_id
ProductSubCategory:
fk: product_id
fk: SubCategory_id
したがって、カテゴリーはコンピューターかもしれません。サブカテゴリは、ウルトラブック、ワークステーション、タブレットです。製品はサムスンのタブレットかもしれません。上記の製品を、関係テーブルを介して「タブレット」サブカテゴリに割り当てます。それから、それが「コンピュータ」でもあると判断できます。
怠惰でスキーマが変更されないことを100%確信している場合は、製品にSubCategory_idを直接ドロップするだけです。関係テーブルは不要です。ただし、サブカテゴリは1つしか持てません。それがあなたが望んでいることかどうかわかりません。
別のユニバースで、自己参照カテゴリテーブルについて考えてみましょう。これにより、任意の数のサブカテゴリレベルが許可されます。
Category:
int: id
str: name
fk: Category_id (null if top level)
データ:
id: 1, name: "Computers", Category_id: null
id: 2, name: "Laptops", Category_id: 1
id: 3, name: "Tablets", Category_id: 1
id: 4, name: "Ultrabooks", Category_id: 2
id: 5, name: "Chromebooks", Category_id: 2
製品が複数の最下位サブカテゴリに含まれる可能性がある場合は、関係テーブルを使用します。それ以外の場合は、製品テーブルにIDをドロップするだけです。握りやすい。