不用担心！它看起来比实际上更复杂！只是去喝酒！
TLDR-version：如何有效地查询和更新与其他实体有关系的实体？
这是一个有趣的数据建模场景，其中包含两个让我感到困惑的表：
Entities { ID, Name, ScalarValue }
ComponentEntities { AggregateEntityID, ComponentEntityID, quantity }
AggregateEntityID并且ComponentEntityID是表的外键Entities。
给我一个血淋淋的例子
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
添加更多这些由级别组成，我们有一个深度关系递归。唯一的限制是实体不能由自身组成。
这似乎形成了一个有向无环图。
RDBMS：“缓存”数据的一种方法是计算相关数据并将其存储在实体本身（或者可能在另一个表中）。在上面的示例中，血腥玛丽的酒精含量将在创建并存储在其酒精百分比字段中时计算一次。在这种情况下，更新变得昂贵，因为我们必须更新由更新的饮料组成的每一种饮料（以及整个依赖层次结构）。
问题
RDBMS：有没有更好的方法来获得叶值（不包含其他值的饮料）而不是在达到叶饮料之前获得“父”饮料？
RDBMS 和 NoSQL 都存在这样的问题：一种方式或另一种方式。
底线：这是否实际可行？
我需要的是一个反盗版
