Cassandra 如何去规范化深层层次结构？

我已经读了很多关于卡桑德拉的书，以及在写数据的时候去规范化和物化的艺术。我想我理解这个概念，而且似乎有道理。但是，在存在深层层次数据结构的场景中，我在实现它时遇到了一些困难

以人为的领域为例，其中

业主1:*公司
公司1:*团队
第一队：*球员
玩家1:*装备

我们为这些实体中的每一个都提供了表，但我们还希望按所有者快速查询设备属性，因此似乎需要创建一个表（OwnerEquipment），其中所有者id和设备id作为主键，所有者id作为分区键。这是有道理的，但是如果添加和编辑设备的用户体验场景没有将所有者id作为工作集的一部分，该怎么办

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

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

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

这是有道理的，但是如果添加和编辑设备的用户体验场景没有将所有者id作为工作集的一部分，该怎么办

简单，将所有者id和设备id一起传递给用户体验。所有者id可以是隐藏值，不显示在界面上

但是，如果您真正想要通过几个“连接”来反规范化的数据呢

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

---

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

谢谢！我对您答案的解释似乎暗示所有的表都需要有所有者id，这样设备表才能有所有者id，这就是为什么？不是所有的表都应该有所有者id。只需将所有者id放在主键中查询所需的位置。我想这说起来容易做起来难。考虑一下我提到的一个公司正在改变所有者的情景。公司表中有一个所有者id，我正在更新它。我唯一关心车主的地方是我自己的设备表。但要更新该表，我需要阅读球队和球员表，以获得要更新的装备列表。听起来对吗？这就是我认为我做错了的地方，因为这基本上是一个连接。我只是在更新中做，而不是在阅读中。