Database design 如何防止实体由相同类型的实体组成的深层递归查询？[里面有一个很酷的例子]

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

TLDR版本：如何高效查询和更新与其他实体有关系的实体

下面是一个有趣的数据建模场景，其中有两个表一直困扰着我：

Entities { ID, Name, ScalarValue }

ComponentEntities { AggregateEntityID, ComponentEntityID, quantity }

AggregateEntityID

和

ComponentEntityID

是

实体

表的外键

给我一个血淋淋的例子吧

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

如果我们想得到血腥玛丽的酒精含量，我们将

从CocktailID==4的饮品中选择*

相当标准；没什么奇怪的。Lisa喜欢通过给它添加一些激情来让它变得更甜美：

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

Lisa的妈妈已经品尝了这么久，她相信她已经找到了两者的完美融合：

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

再加上几个由层组成的，我们就有了一个深层的关系递归。唯一的限制是实体不能由自身组成

这似乎形成了一种矛盾

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

问题
RDBMS：有没有更好的方法来获取叶子价值（不包含其他价值的饮料），而不是在达到叶子饮料之前获取“父”饮料

RDBMS和NoSQL都有这样的问题：一种方式或另一种方式

一句话：这是否切实可行

我需要的是一个反开始

许多RDM支持递归查询。见e。g、 
 “RDBMS：有没有更好的方法来获取叶子价值（不包含其他价值的饮料），而不是在达到叶子饮料之前获取“父”饮料？”

我不明白。不包含其他饮料的饮料与递归无关。这是一个简单的例外或不存在的地方

“获取叶值”（给定父级）将不可避免地需要遍历树，而不管用于对其建模的数据结构（关系或层次）如何，你不这么认为吗

RDBMS和NoSQL都有这样的问题：一种方式或另一种方式

RDBMS在这方面并没有什么问题。这个问题在几十年前（大约80年代）就已经被发现，并通过使用传递闭包操作和它的广义版本来修改关系代数来解决。SQL通过递归查询来支持这一点，正如Frank所说，至少所有的大狗都以这样或那样的方式支持递归查询

一句话：这是否切实可行？”

如果您以前从未编写过递归查询，那么编写递归查询并不是一件小事。这是否会让它变得“不切实际”？我不知道。
传递闭包是缺少的环节！解决方案是通过存储中间路径来简单地展平递归关系。这是一种时空折衷。感谢您的介绍。：D