在Google App Engine中，最有效的多对多联接模型是什么？

在BigTable的设计拒绝了许多标准的关系型模式的哲学的，明确非规范化宁愿到细微的小表的大主机。

问题所在的较大区域之一是对多对多联接的建模。

对这些联接建模的一种方法是违反第一范式，然后将所有有趣的数据放入db.ListProperty（）中。尽管这具有从查询中进行搜索的能力，但我尚未探索搜索列表与提取另一个表的性能含义。

由于连接是不可能的，这是可以通过RelationshipProperties链接表。因此，只要付出足够的努力，就可以创建标准相交表（具有引用两个父表的联合主键的表）。有没有人探索过各种实现的性能影响？

-编辑-

虽然文档中建议的“密钥列表”确实是实现此目的的一种方法，但我对该类和其他实现的性能和异常率感兴趣。创建公用密钥列表是否有用？重复付出的努力值得付出代价吗？有更好的方法吗？

我现在也正在使用GAE数据存储，如果您还没有的话，应该查看这篇文章。如果您发现有用的信息，请更新您的问题。

编辑：

我今天发现了这个，检查一下。

根据我在GAE上的经验，您应该谨慎使用表查询。添加“联接”表只会使事情变慢。例如，如果您具有共享多对多关系的表A和B，并创建一个对A和B都具有RelationshipProperty字段的“联接”表J，则每次要查找时都必须查询J相关记录（实体）。

将键列表包含在A或B中（或在必要时同时包含两者）会更快得多，因为在您获取该记录/实体时将包括它们。只要列表中没有太多键（即实体不是太大），就可以采用这种方法。

我已经开始在应用程序上使用ndb，并且在获取实体时使用密钥有一些明显的好处。如果实体已经被缓存，它将首先从内存或内存缓存中将其提取。因此，如果您的“键列表”中存在大量重叠，则对于已获取的实体，获取会更快。