mongoDB 数据库表设计的基本原则由于mongo 是非关系型数据库，和传统的关系型数据库最大的区别就是，它几乎什么格

由于mongo 是非关系型数据库，和传统的关系型数据库最大的区别就是，它几乎什么格式都能存,这也就造成了在使用场景上可以很灵活和随意。所以很多时候我们如果能合理的设计数据库的表，去优化表之间的关联关系，我相信可以极大的提升使用性能和体验。

以下是我在实际应用场景下，总结出的一些数据库表的设计原则。

1. 一对多：Modeling One-to-Few

{
  name: 'devlifestyle',
  age: "86",
  addresses: [
    { street: "西湖街道", city: "杭州", province: "浙江" },
    { street: "常州大学", city: "苏州", province: "江苏" },
  ]
}

优点：不需要多次查询，一条指令就能获取所有数据

缺点：无法作为一个单独的实例去访问地址

2. 一对许多：One-to-Many

拿我之前做的 ai智能穿搭系统 为例，如果它里面有一个 label 模块用来记录衣服相关的标签（标签的数量一般不会太多），并且可能未来会在某些交互场景下单独复用，那在数据库的表现大概是这样：

// 标签表
{
  _id: ObjectId(Tag1)
  label: '暗黑',
}
​
// 衣服表
{
  _id: ObjectId(Cloth1)
  color: 'red',
  url: 'chat.jzxer.cn/image/shirt.jpg',
  size: 28,
  labels: [
    ObjectId(Tag1),
      ObjectId(Tag2),
  ]
}

注意：在这种模式下，父级嵌套数据量不宜过多，例如在该表中的label应该保持在12以内，或者更少。

3. 一对特别多：One-to-Squillions

这个场景非常普遍，拿一个服务器运维管理后台来说，当这个管理后台录入了多个服务器，而我希望从某一台服务器中存取数据时，由于日志一般数量体积都非常庞大，而 mongodb 的文档有16M的体积限制，所以它的表设计大概如下：

// 服务器表
{
  _id: ObjectId(Host1),
  ip: "10,0,9.3",
  name: "blog.jzxer.cn"
}
​
// 日志表
{
  _id: ObjectId(Log1),
  ip: ObjectId(Host1),    // 服务器Id 
  time: new Date(),
  message: "what you say?"
}

比如我想通过该表找到 '10.0.9.3' 这台服务器下的 2000 条 Log 数据

4. 总结

本文介绍了三种最常见的数据表设计原则：

1. 一对少
2. 一对多
3. 一对非常多

合理的设计数据表结构，有利于产品后续的拓展性和性能的发展。

多花点时间在架构设计上，磨刀不误砍柴工，所有好的产品都是需要精心设计的。

我是dev，下期见（太懒了我，更新频率太低）

个人博客

灵感中心