在Google App Engine中使用祖先或引用属性？

目前，我的很多代码都广泛使用祖先来放置和获取对象。不过，我期待改变一些东西。在Google App Engine中使用祖先或引用属性？

我最初认为，如果你知道你所寻找的实体的祖先是谁，祖先帮助加快了查询速度。但我认为事实证明，祖先对交易支持最有用。我没有利用交易，所以我想知道在这里，祖先对系统的负担是否比帮助更重要。

我拥有的是一个用户实体，还有很多其他实体，比如评论，标签，朋友。用户可以创建很多评论，标签和好友，所以无论何时用户这样做，我都将所有这些新创建的对象的祖先设置为用户。

所以，当我创建一个评论，我设置的祖先为用户：

comment = Comment(aUser, key_name = commentId)

现在唯一的原因，我这样做是严格的查询目的。我认为当我想让某个用户的所有评论获得所有评论的共同祖先而不是查询authorEmail = userEmail的所有评论时，它会更快。

所以，当我想通过一定的用户得到的所有意见，我做的：

commentQuery = db.GqlQuery('SELECT * FROM Comment WHERE ANCESTOR IS :1', userKey)

所以我的问题是，这是一款很好用的祖先？每个评论是否应该有一个引用创建评论的用户对象的ReferenceProperty，并通过该过滤器进行过滤？

（另外，我的想法是，使用的祖先，而不是索引的ReferenceProperty会节省写成本。是我错了吗？）

2012-08-25 Snowman

你是正确的关于写作成本，祖先是关键的一部分来“免费”。如果引用属性被编入索引，那么使用引用属性会增加您的写入成本。
由于您在该引用属性上查询是否需要编制索引。

祖先不仅对交易很重要，如果您不用相同的祖先创建每个评论，HRD（缺省数据存储实现）中的这些quires将不会非常一致。

- 添加尼克的评论---
具有相同父每个实体将是相同的实体组中，并写入实体组进行序列化，因此使用的祖先在这里会慢下来当且仅当你在写多实体并发。由于组中的所有实体都是由组成用户的“所有者”组成的，因此这不应该成为问题 - 事实上，您所做的实际上是推荐的设计模式。

2012-08-25 16:41:29

但是祖先是否会让我放慢脚步？由于他们在写作时提供了额外的安全性，我敢肯定这是有代价的，不是吗？我只是不知道去哪个选项.. – Snowman

我真的不知道，但我相信它并不真正影响查询的速度，因为这个祖先是密钥的一部分，它被用于（某些什么）进行查询时的任何方式。 –

具有相同父代的每个实体都将位于同一个实体组中，并且写入实体组的序列化，因此如果您正在同时编写多个实体，则在此处使用祖先会降低速度。由于组中的所有实体都是由组成用户的“所有者”组成的，因此这不应该成为问题 - 事实上，您所做的实际上是推荐的设计模式。 –

回答