Sql 数据库中的冗余用户生成数据-如何构造？例如，食谱共享成分

我正在建立一个网站，其中大量用户生成的数据将存储在后端数据库中，并将被所有用户发现

就其性质而言，部分用户条目是冗余的。为了举例，让我们假设这些数据是由配方组成的。假设以下条目：

标题：柠檬酱：
-1汤匙柠檬汁
-2汤匙橄榄油
只要混合

及

标题：柠檬卤汁：
-2汤匙柠檬汁
-2汤匙橄榄油
-1汤匙酱油
只要把配料混在一起就行了

显然，这两个条目有一些冗余信息：一半的标题是共享的，部分的指令是共享的，一个成分是完全共享的，另一个成分是部分共享的

此外，人们可以很容易地想象一个由几个子配方组成的配方，这些子配方也可以独立存在。举个例子，你可以用柠檬汁腌制侧翼牛排。因此，配方可以递归定义

我的问题是我应该如何构造我的SQL配方数据库？我的直觉是，在配料表中存储条目“柠檬汁”，在数量表中存储数量“2汤匙”，然后在配方表中使用它们的键是有意义的

但我应该走多远？我是否应该将“柠檬汁”分为两个条目，以防止与“橙汁”和“柠檬味”重复？毕竟，成分也可以递归定义

但是句子也可以，关于如何使用成分的说明也会有一些重叠——但从长远来看，可能不会有那么多。那么单独存储每个单词有意义吗？为什么不写信呢

我不知道如何考虑这样的权衡。我想，如果我尽量减少表中信息的冗余，肯定会有一些成本。它是性能方面的，还是在构思时支付的成本

谢谢,

---

JDelage

在触及领域的基本元素之前，一切都是由某些东西组成的。在餐厅环境中，这些将是厨师所说的配料，即来自食品加工厂或农场的材料。然而，在食品加工厂，这些是输出，而不是输入。我试着把它画在下面，一旦你明白了它是一个事物如何的模型，它就不复杂了

因此，使用表ProductBase对此进行建模

配料、食谱、菜单等都是一样的。它们是由其他物品组成的物品，直到你接触到普遍认为是基本元素的物品，例如柠檬、盐、胡椒、牛排等

因此，如果你有一个配方a，其中包含成分A1、A2等。那么这些成分A1、A2可以是一个配方（即，经过加工以生产某种产品的零件列表），或者是预先准备好的。让数据模型反映这一点

从数据模型中，您不需要区分我们所称的配方、配料等，我将所有这些都存储在一个产品表中，并带有ParentProductID

父产品用于提供容器-列表由其内容定义

链接产品用于定义容器元素引用，即配方有一个成分列表，因此有一个类型为“成分”的条目，其中包含实际使用产品的LinkedProductID

CREATE TABLE `productbase` (
    `productid` CHAR(30) NULL,
    `productname` VARCHAR(200) NULL,
    `parentproductid` CHAR(30) NULL,
    `linkedproductid` CHAR(30) NULL,
    `categoryid` CHAR(30) NULL,
    `supplierid` CHAR(30) NULL,
    `type` CHAR(30) NULL,
    `subtype` INT(11) NULL DEFAULT NULL,
    `cost` DECIMAL(10,4) NULL DEFAULT NULL,
    `mcu` CHAR(30) NULL,
    `mcuperpack` DECIMAL(10,4) NULL DEFAULT NULL,
    `quantity` DECIMAL(10,4) NULL DEFAULT NULL,

---

)除了Richard Harrison所说的之外：我不知道除了DB开发之外是否还进行OOP，但您所描述的是数据库的等价物。我建议研究这方面的实施情况；无论是人们在数据库方面所做的工作，还是在ORM/数据层的OOP方面所做的工作

真棒的回答。事实上，我一直在研究类似的情况（可能是记录食谱等），我可能会从中得到一些想法。干杯