在这种情况下需要一个好的数据库设计

我正在申请一家餐厅。在这种情况下需要一个好的数据库设计

对于一些食品，有一些附加产品可用 - 例如，比萨浇头。

我目前的设计订单表-1

FoodId || AddOnId

如果客户选择单个食品的多个插件（比如Topping和Cheese Dip for Pizza），我该如何管理？

解决方案我想到了 -

IDS通过逗号AddOnId柱（坏主意我猜的）的所有插件在附加组件主表不同的附加物
节能组合分开。
为订购的食品项目制作另一个仅用于插件的转换表。

请建议。

PS - 我搜索了很多类似的问题，但找到了一个。

来源

2013-05-07 Lakshay

你们的关系是这样的：

（1阶）具有有（0或更多浇头）（1个或多个食品项目）。

造成这种情况的最详细的结构将是3个表（除食品和摘心）：

订购
以食品
为了食物，以摘心

现在，了解一些额外的细节。我们开始用一些字段清理表格...

订购
1. 的OrderId
2. 出纳
3. 服务器
4. OrderTime
以食品
1. OrderToFoodItemId
2. 订单ID
3. FoodItemId
4. 尺寸
5. BaseCost
为了食物，以摘心
1. OrderToFoodItemId
2. ToppingId
3. LeftRightOrWhole

通知你有多少信息现在存储的是不依赖于不同的是特定的顺序任何订单？

虽然它可能会出现更多的工作，以保持更多的表，事实是它的结构数据，让您添加很多优点......不是其中最重要的是能够更容易地编写复杂的报表。

来源

2013-05-07 08:23:50

解决方案总是但这已经清除上做的一种方式我的头，现在其服务宗旨。谢谢 – carbonr 2013-08-26 19:09:50

你是对的，首先是一个坏主意，因为它不符合正常形式的表格，并且很难维护它（例如，如果你删除了一些插件，则需要解析字符串以移除id从每一行 - 真的很慢）。

你已经有了表没有错，但该表的主键将是（foodId，addonId）而不是foodId本身。

或者，您可以添加另一个“id”不使用复合主键。

来源

2013-05-07 08:17:28

你想通过它的声音建模两个多对多的现实世界。

即许多产品（食品）可以属于很多订单，很多插件可以属于很多产品：

Orders 
    Id 

Products 
    Id 

OrderLines 
    Id 
    OrderId 
    ProductId 

Addons 
    Id 

ProductAddons 
    Id 
    ProductId 
    AddonId

方案1无疑是一个坏主意，因为它打破甚至第一范式。

来源

2013-05-07 08:17:35 devdigital

你为什么不走了许多一对多的关系。情况：一种食物可以有很多配料，一种配料可以在许多食物中。

你有一个食物表和浇头表与另一个FoodToppings表桥。

这只是一个简单的想法。展开数据库与您的要求

enter image description here

来源

2013-05-07 08:37:20

'FoodToppings'中的Id是主键。图表匆忙。 – 2013-05-07 08:40:36

这种结构适合给特定食物提供浇头。这个问题似乎更多关于下订单，对吧？尼斯图，但！ – 2013-05-07 08:56:19

在这种情况下需要一个好的数据库设计

回答

相关问题