如何非规范化深层层次结构？答案

【问题标题】：How to denormalize deep hierarchies?如何非规范化深层层次结构？
【发布时间】：2016-06-20 15:25:51
【问题描述】：

我在编写数据时阅读了很多关于 Cassandra 以及非规范化和物化艺术的文章。我想我理解这个概念，它似乎是有道理的。但是，在具有深层分层数据结构的情况下，我在实现它时遇到了一些麻烦。

考虑人为设计的域

所有者 1:* 公司
公司 1：* 团队
第 1 队：* 球员
玩家 1：* 装备

我们为每个实体都有表，但我们也想快速查询所有者的设备属性，所以似乎要做的事情是创建一个表 (OwnerEquipment)，其中包含所有者 ID 和设备 ID 作为以所有者 id 作为分区键的主键。这是有道理的，但是如果添加和编辑设备的 UX 场景不包括所有者的 ID 作为工作集的一部分呢？

我在研究中遇到的大多数非规范化示例通常是单级父子或主从类型的用例。更新的客户端在更新子级以写入非规范化反向索引时将有足够的关于直接父级的信息似乎很合理，但是如果您真正想要进行非规范化的数据在几个“连接”之外怎么办？

当我们考虑将公司出售给不同的所有者时，这个问题在我们的示例中更加复杂。假设期望的行为是 OwnerEquipment 反映此更改。将这个更新的公司写入数据库的代码应该如何处理 OwnerEquipment 表的更新？它是否应该在知道旧所有者的 ID 后尝试更新该所有者的所有 OwnerEquipment 记录？这似乎是一件非常不符合 Cassandra 的事情，而且还充满了并发问题。随着您向下移动（团队到新公司，玩家到新团队），问题会变得更糟。在这些情况下，“旧所有者”不一定在工作集中，需要读取才能进行更新。

有没有更好的方法来思考这个问题？

【问题讨论】：

标签： cassandra datastax nosql

【解决方案1】：

这是有道理的，但是如果添加和编辑设备的 UX 场景不包括所有者的 ID 作为工作集的一部分呢？

很简单，将所有者 ID 和设备 ID 一起传递给 UX。 Owner id 可以是隐藏值，不显示在界面上

但是，如果您真正想要进行非规范化的数据在几个“连接”之外怎么办？

为不同的查询用例创建尽可能多的表

对于多个更新和非规范化，您可以查看新的物化视图功能。阅读我的博客：www.doanduyhai.com/blog/?p=1930

【讨论】：

谢谢！我对您的回答的解释似乎暗示所有表都需要具有 owner_id，以便 Equipment 表可以具有 owner_id，这是要去的地方吗？
不是 all 表应该有 owner_id。只需将 owner_id 放在您需要查询的主键中
我想这似乎说起来容易做起来难。考虑一下我提到的公司正在更换所有者的场景。 Company 表中有一个 owner_id，我正在更新它。我关心所有者的唯一其他地方是我的 OwnerEquipment 表。但是要更新该表，我需要阅读 Team 和 Player 表以获取要更新的设备列表。听起来对吗？这就是我认为我做错了的地方，因为这基本上是一个连接。我只是在更新而不是读取时这样做。