我有一个用户数据库,每个用户都有以下属性:
- 用户
- id
- 姓名
- 邮编
- 城市
在关系型数据库中,我会在表user
中建模:
- 用户
- id
- 姓名
- 位置_id
并且有第二个名为location
的表:
- 位置
- id
- 邮编
- 城市
location_id
是对location
表中条目的外键(引用)。
优点是,如果某个城市的邮政编码发生变化,我只需要更改一个条目。
现在我们来看看非关系型数据库,比如Google App Engine。在这里,我会按照规格进行建模。我有一个类型为user
的实体:
class User(db.Model):
name = db.StringProperty()
zip = db.StringProperty()
city = db.StringProperty()
优点是我不需要连接两个表,但缺点是如果邮政编码更改,我必须运行一个脚本来遍历所有用户条目并更新邮政编码,对吗?
在Google App Engine中还有另一种选择,那就是使用ReferenceProperties
。我可以有两种类型:user
和location
:
class Location(db.Model):
zip = db.StringProperty()
city = db.StringProperty()
class User(db.Model):
name = db.StringProperty()
location = db.ReferenceProperty(Location)
我拥有与关系数据库中完全相同的模型。
我刚才做的是错误的吗?
这是否破坏了非关系型数据库的所有优势?
为了获取邮政编码和城市的值,我必须运行第二个查询。但在另一种情况下,要更改邮政编码,我必须遍历所有现有用户。
这两种建模可能性在像Google数据存储这样的非关系型数据库中有什么影响?
它们的典型用例是什么--何时应该使用其中之一?