我有一个项目跟踪应用程序。该应用具有以下实体：
每个project 可以有多个story 和user 实体作为后代。每个story 可以是多个user 实体的父级。基本上，每个项目都有几个用户可以处理项目中的各种故事（任务）。每个故事也可以有多个用户分配给它。如下所示：
现在我的问题是，我可以在应用引擎数据存储中使用祖先查询对这种关系进行建模而不会导致索引爆炸吗？例如，我可以通过简单的查询找出项目中的故事。但是要找出分配给特定用户的故事需要遍历整个故事索引（这并不是真正的问题，因为查询性能与索引表大小无关），但是让查询反映图表不是更好吗喜欢这里的关系吗？好像是用 neo4j 之类的图数据库建模的？
【问题讨论】：
标签： google-app-engine google-cloud-datastore data-modeling graph-databases
如果用户可以处理多个故事，或者目前没有，和/或可以更改他们正在处理的故事（稍后被分配到不同的故事），那么将故事建模为“父”用户在语义层面上似乎大错特错——它也可能导致性能问题（取决于查询类型、读写频率等），但是，这是次要的担忧，我会关注语义首先是正确性，我不完全确定您的数据模型的具体语义。
在 GAE 的数据存储中，父“关系”旨在模拟持久性（实际上我会说“永久”，就子实体的生命周期而言:-) 1:many 连接——尤其是一个很可能要求父母和孩子之间或兄弟姐妹之间的事务行为（甚至只是强一致性）（事务行为和强一致性并不是免费的，性能方面的——但是，当你需要它们时，你真的需要它们:-) .您的应用中的故事和用户之间的联系与此摘要的匹配程度如何？
当然还有其他方法可以模拟持久性 1：许多连接；使用ndb 概念，StructuredProperty 实际上可以让您将“子”实体嵌入“在”“父”实体“内部”（如果您不需要查询子实体的属性，则可以通过使用 local 类型的结构化属性来提高速度）。
当然，建模任何类型关系的最通用方法是使用KeyProperty——这不需要关系是持久的/永久的，也不一定是 1:many（例如，如果可以分配用户多个故事）。实际上，您可以将关键属性视为有向图中的边，其中实体是节点，具有完全的通用性（实际上它可以是一个 multi 有向图，从节点 A 到节点 B 有 0+ 条边，如果您需要比“单纯”图表所能提供的更多通用性:-)。但当然，如果您并不真正需要或使用它，您可以为如此广泛的通用性付出一些代价。
最后，除了实体关系建模的完全清晰性（无论底层是哪种数据库，这都是一件好事：-），“模式”的选择（在最广泛的意义上：- ) 对于 NoSQL 数据库，强烈依赖于应用程序需要的查询、更新等，频率、延迟容忍度、事务性要求、一致性（强与最终）……比关系更高的程度我认为我们大多数人“咬牙切齿”的数据库。因此，我鼓励您努力使这两个方面都非常明确 - 当然是抽象的 E-R 层，但也查询、更新、&c 以及它们的约束和要求的组合。
【讨论】：
StructuredProperty 可能不起作用，因为每个嵌入式实体都需要作为单独的模型。我相信KeyProperty 的想法最适合该应用程序。