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

Question

我正在申请一家餐馆。

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

我目前的订单表设计 -

FoodId || AddOnId

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

我想到的解决方案 -

1. 在AddOnId列中用逗号分隔的ID（我猜是坏主意）
2. 将所有插件的组合保存为Addon主表中的其他插件。
3. 为订购食品制作另一个只有Addon的Trans表。

请建议。

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

Answer 1

您的关系是这样的：

（1个订单）有（1个或多个食品）有（0或更多浇头）。

最详细的结构将是3个表（除了Food Item和Topping）：

1. 顺序
2. 订购食品
3. 订购食品至顶部

现在，了解一些其他细节。让我们开始用一些字段刷新表格......

1. 订单
   1. 的OrderId
   2. 出纳
   3. 服务器
   4. OrderTime
2. 订购食品
   1. OrderToFoodItemId
   2. 的OrderId
   3. FoodItemId
   4. 尺寸
   5. BaseCost
3. 命令食物项目到顶部
   1. OrderToFoodItemId
   2. ToppingId
   3. LeftRightOrWhole

请注意您现在可以存储多少关于订单的信息，该订单不依赖于特定订单以外的任何订单？

虽然维护更多表可能看起来更多，但事实是它构建了数据，为您提供了许多额外的优势......其中最重要的是能够更轻松地编写复杂的报表。

Answer 2

你希望通过它的声音来模拟两个多对多的关系。

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

Orders
    Id

Products
    Id

OrderLines
    Id
    OrderId
    ProductId

Addons
    Id

ProductAddons
    Id
    ProductId
    AddonId

选项1肯定是一个坏主意，因为它甚至打破了第一个正常形式。

Answer 3

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

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

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

Answer 4

为什么不去寻找多对多的关系。 情况：一种食物可以有许多浇头，一种浇头可以放在许多食物中。

你有食物桌和浇头桌以及另一个FoodToppings桥牌桌。

这只是一个简短的想法。根据您的要求扩展数据库