关系数据建模与非关系数据建模

我有一个用户数据库，每个用户具有以下属性：

• user
• id
• name
• zip
• city

In a 关系型数据库我会在表格中对其进行建模user:

• user
• id
• name
• 位置 ID

并有第二个表称为location:

• location
• id
• zip
• city

and location_id是指向条目的外键（引用）location table.

优点是，如果某个城市的邮政编码发生变化，我只需更改一个条目。

让我们去非关系数据库，比如 Google App Engine。在这里，我将按照规范对其进行建模。我有一种user:

class User(db.Model):
    name = db.StringProperty()
    zip = db.StringProperty()
    city = db.StringProperty()

优点是我不需要连接两个表，但缺点是如果邮政编码发生更改，我必须运行一个脚本来遍历所有用户条目并更新邮政编码，对吗？

Google App Engine 中还有另一个选项，那就是使用ReferenceProperties。我可以有两种，user and location:

class Location(db.Model):
    zip = db.StringProperty()
    city = db.StringProperty()

class User(db.Model):
    name = db.StringProperty()
    location = db.ReferenceProperty(Location)

我的模型与关系数据库中的模型完全相同。

难道是我刚才做错了？

这是否会破坏非关系数据库的所有优势？

为了获取邮政编码和城市的值，我必须运行第二个查询。但在另一种情况下，要更改邮政编码，我必须遍历所有现有用户。

在像 Google 数据存储这样的非关系数据库中，这两种建模可能性有何含义？

这两种方法的典型用例是什么——我什么时候应该使用其中一种，什么时候应该使用另一种？

根据我的经验，最大的区别是非关系数据存储迫使您根据查询方式（由于缺乏联接）以及写入方式（由于事务限制）进行建模。这当然会导致模型非常非规范化。过了一会儿，我开始定义所有的查询first，以避免以后必须重新考虑模型。

由于关系数据库的灵活性，您可以单独考虑每个数据系列，在它们之间创建关系，并最终按照您的意愿进行查询（在很多情况下滥用联接）。