映射Google App Engine博客应用程序的数据： [英] Mapping Data for a Google App Engine Blog Application:

问题描述

我的阅读材料迄今为止仍然有限，但到目前为止，这里是我使用GAE数据存储识别的一些关键点：

• 它不是一个关系数据库。


• 在存储空间中默认情况下发生数据重复。


• 无法在数据存储级别加入表。 / li>
  
• 
  
• 
  这些将我引导至以下数据模型：一个博客系统：
  
  

  博客有一套比较着名的'专栏'：id，日期，作者，内容，评分，标签。数据存储允许根据需要添加更多列，但众所周知，即时添加额外列的可能性很少，因为它需要更多的后端专用编码以及更多的整个博客系统。

  
  
  

  博客没有的是一系列评论和标签。在传统的关系数据库结构中，它们通过连接进行映射。由于这些在GAE中是不可能的，所以我想过实施以下内容：
  
  

  
  
  • 文章 - > ID，作者，日期，标题，内容，评分，标签
  
  
  • 评论 - > Article_ID，作者，日期，内容，评分
  
  
  • 标签 - >标签，文章ID
  
  
  
  

  示例：
  
  

  文章 -
  1 - 管理员 - 01/01/2011 - 问题？ - 答案... - 5 - 问题，答案，猜测，反思
  2 - 管理员 - 01/05/2011 - 谁知道？ - 不是我！ - 10 - 问题
  

  评论 -
  1 - 约翰史密斯 - 01/02/2011 - 愚蠢，愚蠢，愚蠢.. - 0
  1 - Jane Doe - 01/03/2011 - 聪明，聪明，聪明.. - 5

  
  
  

  标签 -
  问题 - 1，2
  回答 - 1
  猜测 - 1
  反刍 - 1

  
  
  

  现在，这是我的推理。在浏览博客时，您可以通过以下方式进行操作：日期，作者，标签/主题，评级，评论等。日期，作者和评级是静态的，因此可以轻松地与所讨论的文章一起存放在单个表中。

  
  
  

  标签在'表'和'表'之间重复，但是这里的一致性是在应用程序级别处理的，并且标签留在应用程序中以消除连接在向观众发送文章时的级别。标签表格用于通过标签进行搜索。然后在应用程序级别解析文章列表，然后通过应用程序调用来检索这些文章。

  
  
  

  同样的事情会发生在评论中。通过传递检索到的文章ID的额外方法调用，连接将在应用程序级别发生。

  
  
  

  现在，我为什么要在应用程序级别处理连接？我曾想过在每篇文章中插入所有内容，并在创建时添加评论，但是一旦将博客归入成千上万篇文章，并考虑到返回大小的限制，就必须考虑排序和搜索的时间复杂性，而不是知道可能会有多大的文章/评论。我没有测试过，但考虑到时间复杂性，我开始得出结论，当试图通过标签搜索这些文章时，文章检索将会线性增长到文章数量。我是否正确，并且这种方法是否可以解决这个问题？另外，一般来说，这个数据模型看起来像是一种在GAE中有效实现持久数据存储的方法吗？
  
  

  谢谢，
  试图把我的头包裹起来。 ..

  解决方案

  你的方法听起来很合理。通过标签检索文章最容易实现的方法是在文章上添加一个ListProperty标签并对其进行过滤 - 这将花费与返回的结果数量成正比的时间，而不是数据存储区中的数量 - 并且您是对的应该保留一组单独的标签实体，以便您可以单独列出所有正在使用的标签。

  
  
  

  您可能想查看我的系列文章在App Engine上撰写博客系统。
  

  My reading is limited as of yet, but so far here are some key points I have identified for using the GAE Datastore:

  • It is not a relational database.
  • Data duplication occurs by default across storage space.
  • You cannot 'join' tables at the datastore level.
  • Optimized for reads with less frequent writes.

  These lead me to the following data model for a Blog System:

  Blogs have a relatively known set of 'columns': id, date, author, content, rating, tags. The Datastore allows for additional columns as desired, but it is known that the likelihood of adding additional columns on the fly will be rare as it requires more backend specialized coding as well as more thought to the entire blog system.

  What Blogs do not have are a set number of Comments and Tags. In a traditional relational db structure, these are mapped through a join. Since these are not possible in GAE, I have thought about implementing the following:

  • Articles -> ID, Author, Date, Title, Content, Rating, Tags
  • Comments -> Article_ID, Author, Date, Content, Rating
  • Tags -> Tag, Article IDs

  Example:

  Article- 1 - Administrator - 01/01/2011 - Questions? - Answers… - 5 - questions, answers, speculations, ruminations 2 - Administrator - 01/05/2011 - Who knows? - Not me! - 10 - questions

  Comments- 1 - John Smith - 01/02/2011 - Stupid, stupid, stupid.. - 0 1 - Jane Doe - 01/03/2011 - Smart, smart, smart.. - 5

  Tags- questions - 1, 2 answers - 1 speculations - 1 ruminations - 1

  Now, this is my reasoning. When browsing a Blog you do so by: Date, Author, Tag / Topic, Rating, Comments, etc. Date, Author, and Rating are static and so can easily reside in a single table along with the article in question.

  Tags are duplicated between the tags 'table' and the article 'table', but consistency here is handled at the application level and the tags are left in to eliminate a join at the application level when sending articles to the viewer. The Tags table is used in order to search by tag. The list of articles is then parsed at application level and then it retrieves these articles through an application call.

  The same thing is going to happen with the comments. The join will occur at the application level through an extra method call passing a retrieved article ID.

  Now, why do I want to process a join at the application level? I had thought about inserting everything into each article, adding comments as they were created, but got to thinking about the time complexity of sorting and searching once a blog was into the thousands of articles, as well as the limitations on size of returns, not knowing how large articles / comments might become. I haven't tested, but in thinking of the time complexity, I began to conclude that article retrieval would grow linearly to number of articles when attempting to search these articles by tags. Am I correct in this and is this approach a way to overcome that? Also, in general does this data model look like a way to validly implement persistent data storage in GAE?

  Thanks, Trying to wrap my head around it...

  解决方案

  Your approach sounds pretty reasonable. Retrieving articles by tag is most easily achieved by having a ListProperty of tags on the article, and filtering on that - which will take time proportional to the number of results returned, not to the number in the datastore - and you're right that you should keep a separate set of 'tag' entities so that you can list all the tags in use separately.

  You may want to check out my series of posts on writing a blogging system on App Engine.

  这篇关于映射Google App Engine博客应用程序的数据：的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！