database-design - 如何防止由相同类型的实体组成的实体进行深度递归查询？ [里面很酷的例子]

Question

不用担心!它看起来比实际更复杂!快去喝饮料吧!

TLDR 版 :如何有效地查询和更新与其他实体有关系的实体？

这是一个有趣的数据建模场景，其中有两个表一直让我感到困惑:

Entities { ID, Name, ScalarValue }

ComponentEntities { AggregateEntityID, ComponentEntityID, quantity }

AggregateEntityID和 ComponentEntityID是 Entities 的外键 table 。

给我一个血腥的例子已经

Drinks { ID, Name, Alcohol% }

DrinkIngredients { CocktailID, IngredientID, amount }

Drinks { 1, "Vodka", 40% }
Drinks { 2, "Tomato juice", 0% }
Drinks { 3, "Tabasco", 0% }
Drinks { 4, "Bloody mary", - }

DrinkIngredients { 4, 1, 0.2 } // Bloody mary has 0.2*Vodka
DrinkIngredients { 4, 2, 0.7 } // Bloody mary has 0.7*Tomato juice
DrinkIngredients { 4, 3, 0.1 } // Bloody mary has 0.1*Tabasco

如果我们想获得血腥玛丽的酒精含量，我们会 SELECT * FROM DrinkIngredients WHERE CocktailID == 4 .

相当标准；没有什么奇怪的。 Lisa 喜欢通过添加一些 Passion 让它更甜一点:

Drinks { 6, "Passion", 13% }
Drinks { 7, "Bloody Mary Pink", - }

DrinkIngredients { 7, 4, 0.8 }  // Bloody Mary Pink has 0.8*Bloody Mary
DrinkIngredients { 7, 6, 0.2 }  // Bloody Mary Pink has 0.2*Passion

丽莎的妈妈已经品尝了这么久，以至于她相信她已经找到了两者之间的终极融合:

Drinks { 8, "Bloody Milf", - }
DrinkIngredients { 8, 4, 0.45 } // Bloody Milf has 0.45*Bloody Mary
DrinkIngredients { 8, 7, 0.55 } // Bloody Milf has 0.55*Bloody Mary Pink

添加更多这些 由 组成层次，我们有一个深层的关系递归。唯一的限制是实体不能由自身组成。

这似乎形成了一个 directed acyclic graph .

RDBMS:“缓存”数据的一种方法是计算相关数据并将其存储在实体本身(或可能在另一个表中)。在上面的示例中，血腥玛丽的酒精含量将在创建并存储在其酒精百分比字段中时计算一次。在这种情况下，更新变得昂贵，因为我们必须更新由更新后的饮料组成的每一种饮料(以及整个依赖层次结构)。

问题

RDBMS:有没有比在达到叶子饮料之前获取“父”饮料更好的方法来获得叶子值(不包含其他饮料的饮料)？

RDBMS 和 NoSQL 都存在这样的问题:一种方式或另一种方式。

底线:这甚至实用可行吗？

我需要的是反启动

Answer 1

“RDBMS:有没有比在达到叶子饮料之前获取“父”饮料更好的方法来获得叶子值(不包含其他饮料的饮料)？

不明白这个。不包含其他饮品的饮品与递归无关。这是一个简单的 EXCEPT 或 WHERE NOT EXISTS。

并且“获取叶值”(给定父级)将不可避免地需要遍历树，无论用于对其进行建模的数据结构(关系或分层)如何，您不觉得吗？

RDBMS 和 NoSQL 都存在这样的问题:一种方式或另一种方式。

RDBMS 在这方面并没有真正的问题。这个问题在几十年前(80 年代左右)就已经被发现，并通过使用传递闭包运算及其广义版本修改关系代数来解决。 SQL 通过递归查询支持这一点，正如弗兰克所说，至少所有的大狗都以一种或另一种方式支持递归查询。

底线:这甚至实用可行吗？”

如果您以前从未这样做过，编写递归查询并不是一件容易的事。这是否使它“不切实际”？我不会知道。