针对 Google App Engine 上的论坛应用程序的数据建模建议答案

【问题标题】：Data modeling advice for a forum application on Google App Engine针对 Google App Engine 上的论坛应用程序的数据建模建议
【发布时间】：2011-01-05 23:46:39
【问题描述】：

我正在 Google App Engine 上编写一个类似论坛的简单应用程序，并试图避免可扩展性问题。我是这种非 RBDMS 方法的新手，我想从一开始就避免陷阱。
论坛设计非常简单，帖子和回复将是唯一的概念。如果论坛有数百万个帖子，那么解决问题的最佳方法是什么？

目前的模型（去除了无用的属性）：

class Message(db.Model):  
    user = db.StringProperty() # will be a google account user_id  
    text = db.TextProperty() # the text of the message  
    reply_to = db.SelfReferenceProperty() # if null is a post, if not null a reply (useful for reply-to-reply)

拆分模型，我认为它更快，因为它会在检索“所有帖子”时查询更少的项目：

class Post(db.Model):  
    user = db.StringProperty() # will be a google account user_id  
    text = db.TextProperty() # the text of the message  

class Reply(db.Model):  
    user = db.StringProperty() # will be a google account user_id  
    text = db.TextProperty() # the text of the message  
    reply_to = db.ReferenceProperty(Post)

这是 RDBMS 世界中的多对一关系，应该使用 ListProperty 代替吗？如果有，怎么做？

编辑：

Jaiku 使用类似的东西

class StreamEntry(DeletedMarkerModel):  
...  
    entry = models.StringProperty()     # ref - the parent of this, should it be a comment  
...

【问题讨论】：

我假设您可以回复回复？如果可以的话，这将不会真正有效地工作......

标签： python google-app-engine data-modeling

【解决方案1】：

首先，为什么不使用user = db.UserProperty() 而不是user = db.StringProperty()？

其次，我很确定您应该使用任何可行的并且更具可读性并稍后测试性能，原因有以下三个：

KISS（保持简单）
早期的优化很糟糕
你无法改进你无法衡量的东西

因此，当您准备好进行测量时，请开始优化。

我之所以这么说，不是因为我对 RDBMS、No-SQL DBMS 或 Google 数据存储性能优化一无所知，而是因为我通常从测试中获得所有关于它的知识，这似乎更经常与之前的假设相矛盾超出我的预期。

【讨论】：

我知道过早的优化通常很糟糕，但我正试图将我的思想集中在这个新架构上，学习最佳实践等......此外，模型设计会泄露一切，从对 css 的视图，我最好从一开始就做好:) 我使用的是字符串属性，因为 db.UserProperty 不能保证是静态的，如果用户更改其电子邮件地址，则用户实体将不同，而 user_id保证是永久的。
在我的应用程序中，没有考虑用户更改其电子邮件地址的可能性。关于设计，我最好的选择是使用您提出的第一个模型。

【解决方案2】：

您可能想看看a good tutorial on creating a php forum from scratch。当然，其中一个是关于 PHP 的，但它也涵盖了论坛设计的一般概述。

基本上，不要拆分帖子和回复或主题和帖子。这将在以后导致一些非常尴尬的查询。线程只是一个不回复任何内容的帖子。

【讨论】：