冗余用户在数据库中生成数据 - 如何构建？例如，食谱分享成分

Question

我正在构建一个网站，其中大量用户生成的数据将存储在后端数据库中，并且所有用户都可以发现这些数据。

就其本质而言，一部分用户条目将是多余的。为了举例，我们假设这些数据是由食谱组成的。假设以下条目：

标题：Lemony敷料：
- 1汤匙柠檬汁
- 2汤匙橄榄油
混合！

和

标题：Lemony marinade：
- 2汤匙柠檬汁
- 2汤匙橄榄油
- 1汤匙酱油
只需将各种成分混合在一起！

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

此外，人们很容易想象由几个子食谱组成的食谱，这些食谱也可以单独存在。因此，例如，你可以使用腌制的侧面牛排配方，使用 lemony marinade 作为一个步骤。因此，可以递归地定义食谱。

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

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

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

我不确定如何考虑这样的权衡。我想如果我最小化表中信息的冗余，就必须有一些成本。它是表现明智的，还是在受孕时付出的成本？

谢谢，

JDelage

Answer 1

在您点击域名的基本元素之前，所有内容都由某些内容组成。在餐厅环境中，这些将成为厨师所称的成分，即。来自食品加工厂或农场的东西。然而，在食品加工厂，这些是产出而不是输入。我试图在下面画出这个，一旦你理解它是事物的模型，它并不复杂。

使用表 ProductBase

对此进行建模

配料，食谱，菜单等都是一样的。它们是由其他物品组成的物品，直到您获得通常被认为是基本要素的物品，例如：柠檬，盐，胡椒，牛排等。

因此，如果您有配方A，其中包含成分A1，A2等，则这些成分A1，A2可以是配方（即，为了生产某物而加工的部件清单），或预先准备好的东西。让数据模型反映出来。

从数据模型中，您不需要区分我们称之为食谱，成分等的东西，我将所有这些存储在单个产品表中，使用ParentProductID，

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

Linked产品用于定义容器元素引用，即配方有成分列表，因此有一个INGREDIENT类型的条目，其中包含实际产品的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,

）

Answer 2

除了 Richard Harrison 之外说：除了数据库开发之外，我不知道你是否做了OOP，但你所描述的是与Composite pattern相当的数据库。我建议调查一下这个实现;人们在数据库方面所做的事情，以及ORM /数据层的OOP方面。