我正在开发一个 Web 应用程序,该应用程序允许用户创建简单的网站并将其发布在静态 Web 主机上,但我在决定是否以及如何在必要和可避免的灰色区域中使用祖先时遇到问题。
该模型相当简单:目前每个User
人都有一个或多个Website
实体。实体存储有关网站的Website
所有基本信息,以及引用Page
实体的嵌套导航菜单(导航树存储为 JSON 属性)。实体类型基于Page
PolyModel,并且有几种不同的页面类型(GalleryPage
例如,有一个)。
目前还没有实体组(或者更确切地说,没有具有祖先的实体),我只需要几个事务。例如,当更新页面的名称时,我必须在Page
实体本身以及实体的导航树中更新它Website
。
我想我了解实体组是如何工作的以及使用它们的基本含义,但是在没有充分理由支持这两种方法的情况下,我很难确定构建数据的“最佳”方法。我可以:
在我的实体上完全没有祖先。据我了解,只要我通过密钥获取实体并且事务中不需要超过 5 个,我仍然可以使用跨组事务。缺点是我将依赖 XG 事务,并且可能会出现我无法再使用祖先查询的方式(然后可能为时已晚)。
使用户对象成为他所有网站、页面和其他数据的父对象。这将为用户提供对其所有数据的高度一致的视图,允许我在添加需要它们的功能时使用事务,但将持续写入限制为 1-5/秒。但是,由于用户只会更新他自己的数据,因此对于 1000 个用户来说,这实际上可能会起作用并且行为与 1 个用户相同。
尝试使用更小的实体组(例如将导航与网站分开
Website
并使其成为网站页面的父级)。但我不太确定这样做是否有很多好处,因为无论如何大部分编辑都发生在 Pages 上。
所以我想真正的问题是:当没有明显的理由支持或反对它们时,你如何决定何时在 App Engine 上使用祖先关系?你会为了强一致性查询的便利性而去,并且能够在以后添加功能时自由地使用事务,还是会不惜一切代价避免它们,直到有一个非常明显的原因,即使可能会限制我以后进行事务的能力?
我阅读了相关文档,阅读了“Programming App Engine”中关于事务的章节,看了很多 Google I/O 视频,但我仍然很难做出这个决定。