半年后，NoSql数据库设计有哪些经验之谈？

本文共计1712个文字，预计阅读时间需要7分钟。

NoSql数据库概念广为人知，许多公司和产品都在使用，其优缺点也被详细分析。但内心一直存有一个疑问：它的出现究竟是为了解决什么问题？

NoSql数据库这个概念听闻许久了，也陆续看到很多公司和产品都在使用，优缺点似乎都被分析的清清楚楚。但我心里一直存有一个疑惑，它的出现究竟是为了解决什么问题？

这个疑惑非常大，为此我看了很多分析文章，但却总感觉是隔靴搔痒。为了一探究竟，半年前我决定用Mongodb这个著名的NoSql数据库做个产品试试。只有在真实的使用环境中才能得到最贴切的感受。

一晃眼，半年过去了，现在我能用亲身的体会来谈谈NoSql数据库存在的理由和试图解决的问题了。就像所有的哲学思考都来源于对日常活动的观察一样，我们也从最基本的东西说起吧。

来看这样一个业务要求，用户可以为一本书打分，并且写评论。熟悉数据库结构设计的人看到这一句话脑子里应该瞬间就会出现下面这样的表结构（我这里就不太讲究了，大家意会即可）：

用户信息表，书籍信息表，用户为书籍打分信息表，评论表。

现在假想要做一个显示评论内容的页面，上面会有用户信息和相关书籍的信息，想必大家脑子里已经出现各种select和join了吧。

如果用NoSql还是同样的设计的话，那你会惊喜的发现NoSql数据库的性能简直差到爆。性子火爆的估计当场就要掀桌。

什么破烂数据库，不是号称性能一流的吗！

好吧，性能问题也就不说了，竟然连事务都不支持！？那我同时插入四张表的数据该怎么保持一致？开玩笑的吧！

NoSql数据库此时默默的泪流满面，冤枉啊……你别说，还真是冤枉它了。

先从最基本的设计元素说起，几乎所有的NoSql数据库都没有表（table）的概念，取而代之的是文档（document）。