给MongoDB开发者的50条建议（二）

#第二条 要使你的数据面向未来，那么就对数据进行规范化(Normalize if you need to future-proof data)

 

“面向未来的规范的数据”就是指在未来，不同的应用程序能够以各种不同的方式对规范化过的数据进行查询。

这就假定了你有一些数据集合是要被许多应用程序年复一年的使用，有些数据集合是像这样的，但大多数人的数据是不断发展变化的，一些旧的数据会被更新或是丢弃。大多数的人都希望自己现在的查询能够尽可能的快速高效，但是如果他们在将来改变这些查询，他们将要为新的查询去优化数据库。

 

另外，如果一个应用很成功，其数据集往往变得非常特定于应用程序。这并不是说该数据集不能被应用于多个应用程序，通常你会考虑在其上做“荟萃分析”（meta-analysis）。但是这很难等同于“面向未来”所追求的“在10年内人们可以做任何他们想要的查询”。

 

 

#我的评注：

 

  其实这里的“规范化(Normalization)”并不是指关系型数据库中的"规范化"。这里的规范化其实指的是“reference objects in a different collection”。就是使用我们“#第一条“中的引用。

 

读完这条我有些云里雾里，所以查阅了一些资料，StackOverflow上有一则关于MongoDB Normalization的问答让我高清了一些问题：

http://stackoverflow.com/questions/5841681/mongodb-normalization-foreign-key-and-joining-question

 

评论

3 楼 jonerxq 2012-04-13  

你好：
  我现在有一个数据结构
{
  "location": {
    "latitude": 51.0,
    "longitude": -0.1,
    "altitude": 30.1,
    "accuracy": 1200.1,
    "altitude_accuracy": 10.1,
    "address": {
      "street_number": "100",
      "street": "Amphibian Walkway",
      "postal_code": "94043",
      "city": "Mountain View",
      "county": "Mountain View County",
      "region": "California",
      "country": "United States of America",
      "country_code": "US"
    }
  }
}
你说我这样和
{
  "location": {
    "latitude": 51.0,
    "longitude": -0.1,
    "altitude": 30.1,
    "accuracy": 1200.1,
    "altitude_accuracy": 10.1,
   
      "street_number": "100",
      "street": "Amphibian Walkway",
      "postal_code": "94043",
      "city": "Mountain View",
      "county": "Mountain View County",
      "region": "California",
      "country": "United States of America",
      "country_code": "US"
    }
}
这样查询性能上是不是没什么影响，
我用上面那种方式会不会更面向对象一点

2 楼 洛克刘 2011-11-07  

heywap 写道

感谢楼主的分享。

我有一个子文档嵌套深度为三的对象。

类似这样

[
{
    "_id": 'objectid',
    "month": '2011-11',
    "st": '站号',
    "data": [
    {
        "_id": 'objectid',
        "day": '2011-11-7',
        "data": [
        {
            "_id": 'objectid',
            "datetime": '2011-11-1 15:00:00',
            "a01": [0.5, 0.6, 0.4, 0.9],
            "p02": [150, 260, 148, 894]
        }
       ]
    }
   ]
}
];

不知道这样的嵌套级别对查询有无影响 。

另外有一点也很矛盾。
我的最终的数据要存储在最深的一级中，即包含a01的这个文档中.
每次保存前都要依次判断datetime中的月份文档是否存在(那month的那个文档)，再判断
日期文档是否存在(即包含day的那个文档),如果都存在则保存，只要任意一个不存在，则要先添加父文档。

不知道博主有什么看法？？谢谢。

首先，对于第一个疑问

引用

不知道这样的嵌套级别对查询有无影响 。

多层嵌套对查询没有什么影响。MongoDB是支持多层文档嵌套的。

MongDB中文档嵌套的实质是对象数组。你把你要嵌套的子文档应该看作是一个完整的对象。举个例子：一篇文章，评论，子评论，构成了三个对象。文章去嵌套评论再去嵌套子评论。
看了你的文档结构，可能是我对你的业务关系不是很清晰吧，我觉得对象关系不是很明确。

理由是：

我根据你的文档嵌套关系理解的业务是：某个站点一个月的一天中在不同的时间存在“a01"和“p02”两组数据。你现在抽象的对象是：一个站点和月份的合体对象，一个月份对象，一个时间点上的数据对象，你让这三者嵌套关系有点混乱。而且把月份单独抽出来是否合适？

我的建议：站点对象，详细信息两个对象。

[
   {
      "_id": 'objectid',
      "st":'站号',
      "data":[{
            "_id": 'objectid',
            "datetime": '2011-11-1 15:00:00',
            "a01": [0.5, 0.6, 0.4, 0.9],
            "p02": [150, 260, 148, 894]
        }]
];

将来抽取数据按照data的datetime抽取就好了。

我可能不是很了解你的业务，一点拙见。但是你应该将你要存取的东西抽象成对象，看看他们是否有明确的包含关系。

1 楼 heywap 2011-11-07  

感谢楼主的分享。

我有一个子文档嵌套深度为三的对象。

类似这样

[
{
    "_id": 'objectid',
    "month": '2011-11',
    "st": '站号',
    "data": [
    {
        "_id": 'objectid',
        "day": '2011-11-7',
        "data": [
        {
            "_id": 'objectid',
            "datetime": '2011-11-1 15:00:00',
            "a01": [0.5, 0.6, 0.4, 0.9],
            "p02": [150, 260, 148, 894]
        }
       ]
    }
   ]
}
];

不知道这样的嵌套级别对查询有无影响 。

另外有一点也很矛盾。
我的最终的数据要存储在最深的一级中，即包含a01的这个文档中.
每次保存前都要依次判断datetime中的月份文档是否存在(那month的那个文档)，再判断
日期文档是否存在(即包含day的那个文档),如果都存在则保存，只要任意一个不存在，则要先添加父文档。

不知道博主有什么看法？？谢谢。