我在阅读数据时已经阅读了很多关于Cassandra以及非规范化和物化的艺术。我想我理解这个概念，似乎有道理。但是，在存在深层次数据结构的情况下，我遇到了一些问题。
考虑人为的域名
所有者1：*公司
公司1：*团队
第1队：*球员
玩家1：*装备
我们为每个实体都有表格，但我们也想快速查询所有者的设备属性，所以看起来要做的是创建一个具有所有者ID和设备ID的表（OwnerEquipment）以所有者ID作为分区键的主键。这是有道理的，但是如果添加和编辑设备的UX场景不包括作为工作集一部分的所有者ID？
我在研究中遇到的大多数非规范化示例通常是单级父子或主 - 细节类型用例。更新客户端在更新子节点以写入非规范化反向索引时，有足够的关于直接父节点的信息似乎是合理的，但是如果你真正想要反规范化的数据是几个“连接”呢？
当我们考虑将公司出售给其他所有者时，此问题在我们的示例中进一步复杂化。假设所需的行为是OwnerEquipment反映此更改。将此更新的公司写入数据库的代码如何处理OwnerEquipment表更新？是否应该知道旧所有者的ID，尝试更新该所有者的所有OwnerEquipment记录？这似乎是一个非常非Cassandra-y的事情，也充满了并发问题。当您向下移动链条时，问题会变得更糟（团队到新公司，玩家到新团队）。在这些情况下，“旧所有者”不一定在工作集中，需要阅读才能更新。
有没有更好的方法来考虑这个问题？
答案 0 :(得分：0)
这是有道理的，但如果添加和编辑设备的用户体验方案不包含所有者的ID作为工作集的一部分会怎样呢？
很简单，将所有者ID和设备ID传递给UX。所有者ID可以是不在界面上显示的隐藏值
但是，如果你真正想要反规范化的数据是几个“连接”呢？
为不同的查询用例创建尽可能多的表
对于多个更新和非规范化，您可以查看新的物化视图功能。阅读我的博客：www.doanduyhai.com/blog/？p = 1930