我是数据库新手,从未使用过任何 RDBMS。但是我得到了关系数据库的基本概念。至少我认为我这样做;-)
假设我有一个用户数据库,每个用户都有以下属性:
- 用户
- ID
- 姓名
- 压缩
- 城市
例如,在关系数据库中,我会在一个名为user
- 用户
- ID
- 姓名
- location_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)
如果我没记错的话,我现在拥有与上述关系数据库完全相同的模型。我现在想知道的是,首先,我刚才所做的和所做的是否错了,它破坏了非关系数据库的所有优势。我知道,为了获得 zip 和 city 的值,我必须运行第二个查询。但在另一种情况下,要更改邮政编码,我必须遍历所有现有用户。
那么这两种建模可能性在像谷歌数据存储这样的非关系数据库中的含义是什么。以及它们的典型用例是什么,这意味着我什么时候应该使用一个,什么时候使用另一个。
另外一个问题是,如果在非关系数据库中我可以建模与在关系数据库中建模的完全相同,我为什么要使用关系数据库?
抱歉,如果其中一些问题听起来很幼稚,但我相信它们会帮助一些刚接触数据库系统的人更好地理解。