データベース設計のアドバイス

私は、営業チームが迅速なジョブ見積もりツールとして使用するデータベースを設計しています。デザインの特定の側面についてフィードバックをお願いします。

見積もりは基本的に、事前に定義された「アセンブリ」のリストを選択して、それぞれが合意された価格で作成されます。メインフォームの簡略表示は次のようになります。

                                                  +------------ --- ---+
                                                  | Assembly options   |
+------------+------------+----------+------------+---+---+---+ --- +--+
| assembly ▼ | unit cost  | quantity | total cost | 1 | 2 | 3 |     |50|
+------------+------------+----------+------------+---+---+---+ --- +--+
| VSD55      | £10'000    | 2        | £25'500    | 1 | 1 |   |     |  | 
| RDOL2.2    | £2'000     | 1        |  £1'500    |   | 1 |   |     |  | 
| DOL5.0     | £1'000     | 1        |  £1'200    |   |   | 1 |     |  | 
+------------+------------+----------+------------+---+---+---+ --- +--+

ユーザーは事前定義されたアセンブリを選択し、数量を入力して、必要な「オプション」を選択します。各アセンブリには、最大で50の使用可能なオプションがあります。オプションは、独自の価格を持つ事前定義されたアセンブリ（サブアセンブリ）でもあります。各ラインの「総コスト」は、（メインアセンブリコスト*数量）+オプションのコストとして計算されます。

ユーザーがカーソルをオプションボックスに移動すると、そのオプションの名前と価格がユーザーに通知されます。

ここが複雑になるところです。各アセンブリには、使用可能なオプションの独自のリストがあります。つまり、「VSD55」のオプション1は、DOL5.0のオプション1とは異なるサブアセンブリを表します。

アセンブリがここに行く限り、私が使用している簡略化されたテーブルがあります：

+-----------------+    +------------------------+    +-----------------------------+
| assembly        |    | assembly_option        |    | assembly_option_link        |
+-----------------+    +------------------------+    +-----------------------------+
| assembly_id (PK)|    | assembly_option_id (PK)|    | assembly_option_link_id (PK)|
| assembly_name   |    | assembly_option_name   |    | assembly_id (FK)            |
| unit_cost       |    | option_number          |    | assembly_option_id (FK)     |
+-----------------+    | unit_cost              |    +-----------------------------+
                       +------------------------+

テーブル 'assembly_option_link'は基本的に、各アセンブリで使用できるオプションを定義します。

次に、「quote」テーブルについて：

 +-----------------+    +------------------------+    
 | quote           |    | quote_assembly         |    
 +-----------------+    +------------------------+    
 | quote_id (PK)   |    | quote_assembly_id (PK) |
 | quote_name      |    | assembly_id (FK)       |
 +-----------------+    | quantity               |
                        +------------------------+    

ここでトリッキーな部分は、選択したオプションを保存する方法です。これは正規化ルールに違反していますが、「quote_assembly」テーブルを50個のオプションフィールドすべてで拡張する必要があります。アセンブリは50のオプションすべてで選択されることはないため、これも非常に非効率的です。プラス面として、このソリューションでは、ユーザー入力フォームをテーブルに直接マップして、コーディングを簡単にすることができます。

「正規化された」解決策は、次のような別のテーブルを作成することだと思います。

+------------------------------+
| quote_assembly_option        |
+------------------------------+
| quote_assembly_option_id (PK)|
| quote_assembly_id (FK)       |
| assembly_option_id (FK)      |
| quantity                     |
+------------------------------+

このソリューションは、選択されたオプションのみが保存されることを意味します。また、option_numberを保存するのではなく、実際の 'assembly_option_id'を保存できます。これにより、アセンブリオプションコストを検索するために「option_number」と「assembly_option_id」を変換する必要がないため、合計見積もりコストの計算がより簡単になります。ただし、このソリューションの主な欠点は、ユーザー入力フォームにうまく対応できないことです。フォームとテーブルのインターフェースをとるために、いくつかの凝ったコーディングを適用する必要があると思います。

誰かがここで設計アドバイスを提供できますか？私は自分自身を十分に説明したことを願っています。

MORE INFO
ザはまた、本体の下に別の行項目として、任意の選択されたオプションを拡張詳細引用レポートです。例えば：

+---------------------------------+------------+----------+------------+
| assembly                        | unit cost  | quantity | total cost |
+---------------------------------+------------+----------+------------+
| VSD55                           | £10'000    | 2        |   £20'000  |
|   - Seal leak protection        | £ 5'000    | 1        |   £ 5'000  |   <-option 1
|   - Motor over temp protection  | £   500    | 1        |   £   500  |   <-option 2
+---------------------------------+------------+----------+------------+
|                                 |            |          |   £25'500  |
+---------------------------------+------------+----------+------------+

                                                  +------------ --- ---+
                                                  | Assembly options   |
+------------+------------+----------+------------+---+---+---+ --- +--+
| assembly ▼ | unit cost  | quantity | total cost | 1 | 2 | 3 |     |50|
+------------+------------+----------+------------+---+---+---+ --- +--+
| VSD55      | £10'000    | 2        | £20'000    | 1 | 1 |   |     |  | 

誰かがその引用を私に渡した場合、私の最初の質問は「VSD55のオプション1は何ですか？」でしょう。答えは「わからない」。その情報は引用に含まれていません。万が一、その人が2番目の質問に答えた場合、その質問は「いくらかかりますか？」繰り返しになりますが、答えは「わかりません」です。非常に不穏な沈黙がすぐに続き、その間、見積もりを私に渡した人は、電車にひかれるのがどれほど気持ちがよいか想像します。

オプションは、単価、数量、および合計価格とともに、見積もりの​​品目である必要があります。オプションには番号を付けるのではなく、名前を付ける必要があります。彼らはまた、彼らの親集会の真下に現れるべきであり、地獄とジョージアの半分に散らばってはいけません。

あなたは私のお金でショットをしたい場合は、より良い、それは結晶は、私がすることになってるものをクリア作ると思いき私のお金のため。

ユーザーインターフェイスフォームの50個のチェックボックスに問題はありません。これにより、オプションを簡単に選択できます。ただし、UIコードはチェックボックスを読み取り、正規化されたテーブルに正しい情報を挿入する必要があります。

あなたが与える最後のオプションは、私がそれで行く方法です。そして、2つのグループ化されたテーブルを返します。1つは「メイン行」用で、もう1つは50列の「収集された存在」行用です。オプションを適切な列IDに十分に簡単にマップできると仮定します（あまり苦労せずにできるように見えます）。

これは、LINQが利用可能なC＃などの言語を想定して、反復するのに十分簡単です。これらは、ループが少し含まれている場合でも、簡単に実行できます（UIコードなので、ある時点で実行する必要があります） ）。または、返す前にデータベースでピボットを実行することもできます...高速です。しかし、それでも複雑さは維持されます。

しかし、あなたのデザインは私には音に聞こえます。

余分なテーブルを追加することも、私にとってはかなり健全に思えます。

私の側で同様の問題を扱うとき、私はorder_linesテーブルにツリーを格納することを検討しました。あなたが同様のものを検討した場合、私は持っていました：

• の追加parent_idフィールドorder_lines、および(parent_id, product_id)参照するための外部キー(order_line_id, product_id)

• オプションを持つようにするためのチェック制約は、親（私の場合check((option_id is not null) = (parent_id is not null))）を意味します。

言い換えると、UIに、物をどのように保存するかについて一言伝えておきます。

+---------------------------------+------------+----------+------------+
| assembly                        | unit cost  | quantity | total cost |
+---------------------------------+------------+----------+------------+
| VSD55                           | £10'000    | 2        |   £20'000  |
|   - Seal leak protection        | £ 5'000    | 1        |   £ 5'000  |
|   - Motor over temp protection  | £   500    | 1        |   £   500  |
+---------------------------------+------------+----------+------------+

UIコーディングの観点からは、正しいように見えました。しかし、それはビジネスルールの観点からすぐに間違っていると感じました。（私はトリガーであらゆる種類の特別なケースを扱わなければなりませんでした。）

だから、お勧めできません ...ではこれまでのところ、私は似たようなケースを経験してきたように、あなたの現在のアプローチは、以下の問題が発生しやすい道になります。