我的阅读是有限作为然而，但到目前为止，这里是我已经确定了使用GAE Datastore的一些关键点：映射数据对谷歌App Engine的博客应用：
- 它不是一个关系型数据库。
- 数据重复默认跨存储空间发生。
- 您不能在数据存储级别“加入”表。
- 针对写入频率较低的读取进行了优化。
这些使我的博客系统以下数据模型：
博客有一个相对组已知的“列”的：ID，日期，作者，内容，等级，标签。数据存储允许根据需要添加更多的列，但众所周知，即时添加额外列的可能性很少见，因为它需要更多的后端专用编码以及对整个博客系统的更多思考。
博客没有的是一系列评论和标签。在传统的关系数据库结构中，它们通过连接进行映射。由于这些是不可能在GAE，我曾经想过执行以下操作：
- 文章 - > ID，作者，日期，标题，内容，评分，标签
- 评论 - > ARTICLE_ID，作者，日期，内容，评分
- 标签 - >标签，标识条
例子：
物品─ 1 - 管理员 - 01/01/2011 - 问题？ - 答案... - 5 - 问题，答案，猜测，反刍 2 - 管理员 - 01/05/2011 - 谁知道？ - 不是我！ - 10 - 问题
评论 - 1 - 约翰·史密斯 - 01/02/2011 - 愚蠢，愚蠢，愚蠢。 - 0 1 - 李四 - 01/03/2011 - 智能，智能，智能.. - 5
Tags- 问题 - 1，2个 答案 - 1个 猜测 - 1个 沉思 - 1
现在，这是我的推理。在浏览博客时，您可以通过以下方式进行操作：日期，作者，标签/主题，评级，评论等。日期，作者和评级是静态的，因此可以与所讨论的文章一起轻松驻留在单个表中。
标签在标签'table'和文章'table'之间被复制，但是这里的一致性是在应用程序级别处理的，并且在将文章发送给查看器时，标签留在应用程序级别以消除连接。标签表格用于通过标签进行搜索。然后在应用程序级别分析文章列表，然后通过应用程序调用检索这些文章。
同样的事情会发生与评论。连接将通过传递检索的文章ID的额外方法调用在应用程序级别发生。
现在，我为什么要在应用程序级别处理连接？我曾想过在每篇文章中插入所有内容，并在创建时添加评论，但是一旦将博客归入成千上万篇文章，并考虑到返回大小的限制，就必须考虑排序和搜索的时间复杂性，而不是知道可能会有多大的文章/评论。我没有测试过，但考虑到时间复杂性，我开始得出结论，当试图通过标签搜索这些文章时，文章检索将会线性增长到文章数量。我是否正确，并且这种方法是否可以解决这个问题？此外，这种数据模型通常看起来像是在GAE中有效实现持久数据存储的一种方式？
谢谢， 试图环绕它我的头......