Dav*_*vid 9 database-design database-recommendation
我正在为我们的销售团队设计一个数据库，用作快速工作报价工具。我想要一些关于设计特定方面的反馈。
报价基本上是通过选择一个预定义的“组件”列表来建立的，每个“组件”都具有商定的价格。主窗体的简化视图如下所示：
+------------ --- ---+
| 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_assembly |
+-----------------+ +------------------------+
| quote_id (PK) | | quote_assembly_id (PK) |
| quote_name | | assembly_id (FK) |
+-----------------+ | quantity |
+------------------------+
现在棘手的部分是如何存储任何选定的选项。即使这违反了规范化规则，我是否应该使用所有 50 个选项字段扩展“quote_assembly”表。永远不会选择具有所有 50 个选项的程序集，因此这似乎也非常低效。从好的方面来说，该解决方案允许用户输入表单直接映射到表格，从而简化编码。
我认为“标准化”的解决方案是创建另一个这样的表：
+------------------------------+
| quote_assembly_option |
+------------------------------+
| quote_assembly_option_id (PK)|
| quote_assembly_id (FK) |
| assembly_option_id (FK) |
| quantity |
+------------------------------+
此解决方案意味着仅存储选定的选项。此外，我可以存储实际的“assembly_option_id”，而不是存储 option_number。这使得计算总报价成本变得更简单，因为我不需要在 'option_number' 和 'assembly_option_id' 之间进行转换来查找装配选项成本。但是，此解决方案的主要缺点是它不适用于用户输入表单。我想我需要应用一些花哨的编码来将表单与表格连接起来。
任何人都可以在这里提供任何设计建议吗？我希望我已经很好地解释了自己。
更多信息
这也是一份详细的报价报告，可将任何选定的选项扩展为主组件下的单独行项目。例如：
+---------------------------------+------------+----------+------------+
| 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 |
+---------------------------------+------------+----------+------------+
+------------ --- ---+\n | Assembly options |\n+------------+------------+----------+------------+---+---+---+ --- +--+\n| assembly \xe2\x96\xbc | unit cost | quantity | total cost | 1 | 2 | 3 | |50|\n+------------+------------+----------+------------+---+---+---+ --- +--+\n| VSD55 | \xc2\xa310\'000 | 2 | \xc2\xa320\'000 | 1 | 1 | | | | \n如果有人将此报价交给我，我的第一个问题将是“VSD55 的选项 1 是什么？” 答案是“我不知道”。该信息不在报价单上。万一这个人要回答第二个问题，这个问题将是“它的成本是多少？” 同样，答案是“我不知道”。紧接着就会出现令人不安的沉默，在此期间，递给我这句话的人会想象被火车碾过的感觉该有多好。
\n\n选项必须是报价单上的项目，及其单价、数量和总价。选项必须命名，而不是编号。他们也应该直接出现在他们的父议会之下，而不是分散在地狱和佐治亚州的一半。
\n\n如果你想抢我的钱，你最好说清楚我应该用我的钱得到什么。
\n\n用户界面表单上的 50 个复选框并没有什么（太大）问题。这使得选择选项变得很容易。但 UI 代码应该读取复选框并将正确的信息插入规范化表中。
\n