-1

通常のデータベースでは、水平方向に拡張する必要がないという問題があります。

私は店を持っていますProduct。例えば衣料品店。Colorと の間で選択できる店舗の数に制限はありませんSize。私は今のところこれらを呼びますTypes

テーブルは次のようになります。

Product

  • Product name

ProductTypes

  • ProductId
  • TypeId1
  • TypeId2
  • Price
  • Weight
  • Stock
  • Etc...

Types

  • TypeId
  • Type name

とが同じテーブルにまだ一緒にあるためTypeId1、実際には正規化されていません。TypeId2顧客は、タイプ間のすべての相関関係を含む 10D マトリックスを効果的に作成する製品に 10 個のタイプを割り当てたいと考えているかもしれませんが、その場合TypeIdProductTypesテーブルにさらに 8 個の を作成する必要があります。

これは、水平方向にスケーリングすることなく適切に正規化できますか?

たとえば、次のタイプがあります: ColorSizeGenderおよびShape

Blue XL Male Turtleneck主力商品shirtの在庫がなく、価格が変更されたと言える必要があります。しかし、より多くのタイプを製品に動的に追加できるようにする必要があります。

基本的に私は、合理的なデータベースに 5 次元配列ルックアップを格納する方法を尋ねています。

4

2 に答える 2

3

あなたは近くにいます。

テーブルは次のようになります。

Product
-------
Product ID
Product Name
Weight
Stock Number
...

製品 ID は、プライマリ (クラスタリング) キーとして定義される自動インクリメント整数です。あなたの設計に基づいて、重量と在庫数が製品に属していると思います。item と type に属するすべての属性は、後で説明する ItemType テーブルに移動できます。

Type
----
Type ID
Type Name
Type Value
...

タイプ ID は増分整数です。タイプ ID とタイプ値を組み合わせて、プライマリ (クラスタリング) キーにします。

つまり、(0, サイズ, S)、(0, サイズ, M) などです。必要に応じて、これを 2 つの個別のテーブルに分割して、さらに正規化することができます。この単一のテーブルを使用すると、型の行を視覚的に確認しやすくなります。

Item
----
Item ID
Product ID
SKU
Quantity On Hand
Price
...

アイテム ID は、プライマリ (クラスタリング) キーとして定義された自動インクリメント整数です。Product ID は Product テーブルへの外部キーです。インベントリ内のタイプのすべての組み合わせ (すべての固有のアイテム) は、このテーブルで定義されます。例として、アイテム ID 16 はメンズ ワイシャツ (商品)、ブルー (タイプ)、XL (タイプ)、SKU MD-14850639 です。これらのタイプ属性は、ItemType テーブルにまとめられています。

ItemType
--------
Item ID
Type ID
...

アイテム ID とタイプ ID を組み合わせて、プライマリ (クラスタリング) キーにします。1 つのアイテムに必要な数のタイプを含めることができます。

于 2013-11-03T01:26:17.760 に答える