我的阅读时间有限，但到目前为止，我已经确定了使用GAE数据存储区的一些要点：
这些引导我进入博客系统的以下数据模型：
博客有一组相对已知的“列”：id，日期，作者，内容，评级，标签。数据存储区允许根据需要添加其他列，但众所周知，即时添加其他列的可能性很小，因为它需要更多的后端专用编码以及对整个博客系统的更多考虑。
博客没有的是一定数量的评论和标签。在传统的关系数据库结构中，这些通过连接进行映射。由于这些在GAE中是不可能的，我考虑实现以下内容：
示例：
物品─ 1 - 管理员 - 01/01/2011 - 问题？ - 答案...... - 5 - 问题，答案，推测，反思 2 - 管理员 - 01/05/2011 - 谁知道？ - 不是我！ - 10 - 问题
评论 - 1 - 约翰史密斯 - 01/02/2011 - 愚蠢，愚蠢，愚蠢...... - 0 1 - Jane Doe - 01/03/2011 - 聪明，聪明，聪明...... - 5
Tags- 问题 - 1,2 答案 - 1 猜测 - 1 反刍 - 1
现在，这是我的推理。浏览博客时，您可以通过以下方式执行此操作：日期，作者，标签/主题，评级，评论等。日期，作者和评级是静态的，因此可以轻松地与相关文章一起存放在单个表格中。
标签在“表格”和文章“表格”之间重复，但此处的一致性在应用程序级别处理，并且在向查看器发送文章时，标签会留在应用程序级别以消除连接。 Tags表用于按标签搜索。然后在应用程序级别解析文章列表，然后通过应用程序调用检索这些文章。
评论也会发生同样的事情。通过传递检索到的文章ID的额外方法调用，将在应用程序级别进行连接。
现在，为什么我要在应用程序级别处理联接？我曾考虑过在每篇文章中插入所有内容，在创建时添加注释，但是考虑到博客进入数千篇文章后排序和搜索的时间复杂性，以及返回大小的限制，而不是知道可能会有多大的文章/评论。我没有测试过，但是考虑到时间的复杂性，我开始得出结论，当试图通过标签搜索这些文章时，文章检索会线性增长到文章数量。我在这方面是否正确，这种方法是否可以克服这种情况？此外，通常这个数据模型看起来像是在GAE中有效实现持久数据存储的方法吗？
谢谢， 试图绕过它...
答案 0 :(得分：2)
你的方法听起来很合理。通过在文章上使用ListProperty标签并对其进行过滤（这将花费时间与返回的结果数量成比例，而不是数据存储中的数字），最容易实现按标签检索文章 - 你是对的。应该保留一组单独的“标记”实体，以便您可以单独列出所有正在使用的标记。
您可能想要在App Engine上撰写博客系统时查看我的series of posts。