我正在申请一家餐馆。
对于某些食品,有一些可用的附加组件 - 例如比萨的浇头。
我目前的订单表设计-
食品标识 || AddOnId
如果客户为单一食品选择多个插件(例如披萨的浇头和奶酪蘸酱),我将如何管理?
我想到的解决方案——
- 在 AddOnId 列中用逗号分隔的 ID(我猜是个坏主意)
- 将所有插件的组合保存为插件主表中的不同插件。
- 为订购的食品制作另一个仅插件的 Trans 表。
请建议。
PS - 我搜索了很多类似的问题,但找不到一个。
我正在申请一家餐馆。
对于某些食品,有一些可用的附加组件 - 例如比萨的浇头。
我目前的订单表设计-
食品标识 || AddOnId
如果客户为单一食品选择多个插件(例如披萨的浇头和奶酪蘸酱),我将如何管理?
我想到的解决方案——
请建议。
PS - 我搜索了很多类似的问题,但找不到一个。
你们的关系是这样的:
(1 个订单) 具有 (1 个或多个食品) 具有 (0 个或多个浇头)。
最详细的结构将是 3 个表(除了食品和浇头):
现在,关于一些额外的细节。让我们开始用一些字段刷新表......
请注意,您现在可以存储多少关于除了该特定订单之外不依赖于任何东西的订单的信息?
虽然维护更多表格似乎需要更多工作,但事实是它可以构建您的数据,从而为您带来许多额外的优势……其中最重要的是能够更轻松地编写复杂的报告。
你想通过它的声音来模拟两个多对多的关系。
ie很多产品(食品)可以属于很多订单,很多插件可以属于很多产品:
Orders
Id
Products
Id
OrderLines
Id
OrderId
ProductId
Addons
Id
ProductAddons
Id
ProductId
AddonId
选项 1 肯定是一个坏主意,因为它甚至打破了第一范式。
你是对的,第一个是一个坏主意,因为它不符合正常形式的表格并且很难维护它(例如,如果你删除一些插件,你需要解析字符串以从每一行中删除 id -真的很慢)。
拥有您已经拥有的表并没有错,但是该表的主键将是 (foodId, addonId) 而不是 foodId 本身。
或者,您可以添加另一个“id”以不使用复合主键。
你为什么不去多对多的关系。情况:一种食物可以有多种配料,一种配料可以有多种食物。
你有一个食物表和一个浇头表和另一个 FoodToppings 桥表。
这只是一个简短的想法。根据您的要求扩展数据库