Database design &引用；“多重继承”；数据模型中的（概化关系）

对于一些学校的小组工作，我正在制作一个通用的比萨饼递送一切管理系统，在数据建模过程中遇到了一个问题，如果不使用至少几层数据，我就无法解决这个问题

餐厅备有原料和饮料/零食等（我称之为“饮料”）。饮料有卖的价格。该应用程序存储菜谱——每道菜都有一组配料、用量以及售价。订单上有食谱和饮料，但没有配料——直接销售面粉是没有意义的

因此，我需要在配料和饮料之间进行“可储存”的概括，以及在饮料和食谱之间进行“可销售”（或“菜单项”）的概括；我真的记不起ERD建模允许多重概括

（目前，我只是选择了菜单项1，并决定让可储存的东西具有单独的实体层次结构，并在应用程序代码中处理它。我正在考虑删除单独的层次结构，并且根本不在数据模型中表示配料/饮料的差异，而是使用“is配料”标志属性。）

我是否缺少一些东西可以让我在不必处理应用程序代码中的任何内容（或尽可能少地）的情况下对此进行建模

如果有人喜欢做这种脑力练习/拼图游戏，为了获得更多乐趣，放弃的功能包括：

• 按不同税率分类的饮料——认为软饮料和白酒的税率不同；菜肴也有税率，但不属于一个类别
• 出售/部分/配料是有意义的——配料（对于想要额外培根但不想要橄榄的人）；我们还必须存储一份“额外”服务中的配料数量

---

难道没有一个简单的解决方案可以让你拥有一张配料表或可储存物品表，其中包括饮料和其他可能单独列出的配料。这些都不能直接订购

---

然后，您就有了一个菜单项表，这些菜单项都是成分/可储存项目的集合。菜单项集合可能只有一个项目-对于饮料而言，可能总是这样，但也可能包括一片柠檬。

SQL不直接支持继承或泛化的概念。表之间的关系只是引用关系。因此，没有“is-A”机制

您可以使用外键表示“属于”（如“此饮料属于税率为8%的商品类别”），也可以使用外键表示“有一种”（如“此成分有一种母体”）

您可以使用设计支持单独的层次结构，允许一个项目属于多个树

---

既然这是一个家庭作业问题，我就到此为止，剩下的留给你。：-）

我曾在一家食品成本控制系统公司工作。我建议在家庭作业中尽量采用最简单的模式。