产品捆绑在一起的产品的数据库设计

我正在为零售业务建立数据库系统。我设置了一些表，它们是：

• 产品
• 采购
• 营业额
• 平衡

所有这些相互连接，并且能够显示我的库存水平。

我遇到的问题是我还销售捆绑销售的产品-价格与单个产品价格不同。
示例：我以1美元的价格出售一个橙子，以1.2美元的价格出售一个苹果；我以3.8美元的价格出售水果套餐1（2个橙子和2个苹果），以7美元的价格出售水果2包（4个橙子和4个苹果）。

有没有正确的方法来为这些产品捆绑创建关系？

PS：我正在使用FileMaker Pro创建它。

您所描述的模式通常称为“ 零件爆炸 ”或“ 物料清单”。它是数据结构研究中图和树部分的一部分。解决方案的本质是要认识到任何给定的“产品”都可以由其他“产品”组成。然后，设计就是一个网络结构，其中有一个Product表，其中每个产品都有一个行（无论是否由其他产品组成），然后是一个Product Component表，其中每个产品都有一个行，其中每个产品都由其他产品组成，作为该产品组成部分的每个相应产品。就您而言，每种产品都有价格。所以你会有这样的事情

Product
-----------------------------------
|Name             |Price          |
-----------------------------------
|Orange           |1             |
|Apple            |1.20          |
|Fruit Package    |3.80          |
-----------------------------------

Product Component
----------------------------------------------------------
|Product               |Contains                |Quantity|
----------------------------------------------------------
|Fruit Package         |Orange                  |2       |
|Fruit Package         |Apple                   |2       |
----------------------------------------------------------

这种设计比具有递归关联的单个表更可取，因为它干净地将真正的两种实体类型（节点和链接）分开。在我们的例子中，产品是节点，产品组件是链接。

虽然网络设计是一种常见的结构，但是查询它是有问题的，因为当它完全填充时，它是一个深度可变的递归结构。具有行业实力的DBMS（例如Oracle和SQL Server）具有特殊的语言元素（Oracle的CONNECT BY和SQL Server的递归CTE）来帮助使查询具有声明性。鉴于您使用的是我所知甚少的File Maker Pro，因此您可能没有这种语言构造来提供帮助，并且可能不得不编写过程代码来遍历网络。但是，如果网络具有固定的深度，则可以缓解此问题-说每个产品都没有组件，或者没有一个组件级别。以下是有关数据库设计中网络结构的一些参考：

1. 实践问题数据库管理 - 法比安·帕斯卡尔。第7章提供了我发现的最好，最容易理解的解释。
2. Joe Celko的《 SQL for Smarties中的树和层次结构》，第二版。这是一本关于SQL标准特定主题的完整书籍。
3. 企业模型模式 - 戴维·海。关于所有组织通用模式的书（不幸的是，ER图以UML提出，但是可以克服），其中有一些网络结构的示例。