数据库已死(网友观点)

我不同意什么“数据库已死”的说法，但我也不同意在系统设计阶段就让设计数据库的工作掺和进来，我想这也是楼主想说的。

我不止一次地在项目中听到人说：“干嘛折腾什么业务逻辑的设计，把数据库设计好了，你想显示什么，一个sql语句就能搞定。”说这话的人大概没有想过：“干嘛折腾什么高级语言，把汇编学好了，什么软件编不出来。”很多时候，数据库的结构设计好了，并不能表示完成系统设计也指日可待了。若在设计阶段就轻视业务逻辑层面上的面向对象的设计，后续的工作将举步维艰。

举个真实的例子，很多购物系统都会有“order”这么个东西，系统或大或小，或简或繁，但是设计数据表是很轻松的：“分析order从哪来，到哪去，就知道了它需要哪些字段，然后再加上一些额外的字段作为备用，这样不管它将来怎么变，总该万变不离其宗吧！”

数据表都有了，当然该写程序了。当功能即将完工时，客户提出，有些订单项，当它跟另一个订单项在一起时，是可以自动作为赠品的；有一些商品需要捆绑销售，order要打个折扣。

Leader（或者项目经理）觉得这种变更不会影响到数据表，改起来应该很容易，但真正改起来，却牵一发而动全身：系统到处冒bug和exception，程序员的头上也差点要冒烟。

好不容易改好了，客户看完又提出，order可以有多个发货地址。多简单的一句话啊，可是触碰到数据表的修改了，不用说，又是一阵捉虫的恶战。

后来客户又提出，order可以用打折码来打折，可以用礼券来抵价……面对这种屡次三番的修改，以数据库设计为出发点的系统，稳定性能怎样？而一个购物系统的order处理都不稳定，又有谁敢用呢？

这就是重数据库设计，轻对象设计的恶果，因为仅凭数据表和E-R图，很难考虑到对象继承、多态等基本的代码重用设计，更别说设计模式了。我敢说，每天都有软件公司、开发团队发生这样的事。而千万不要说为什么一开始不把需求弄清楚，因为需求的变化是永远存在的。

这样说，岂不是软件开发做不下去了？其实不然，GOF的设计模式就能够很好地面对这些变化，设计模式最强大的地方就是，它虽然不能告诉你需求会怎样变，但它总能够给变化留下空间，让变更的过渡更加容易。

实际上，做应用软件的，就应该以面向对象的系统设计为主，数据库的设计随后跟上。如果有疑问，那么可以想象一下这样的情形：

假设Amazon提供一个数据持久化的服务，不管你使用什么语言，只要你把对象传给它，它就能给你存起来，下次你取出来，还能照样用。这样你就不用管数据库的设计了，想管也管不了了，就可以专心去做面向对象的设计了。经历了若干次的变动和修改，你的软件交付了。直到有一天，Amazon告诉你，其实它们一直是用Mysql存储你的数据的。它们给你一个数据库的备份和一个ORM层的实现，就不用连接它的服务器了。那么各位你一定不会觉得难办，因为你的面向对象的系统设计已是完好的，更换的只是一个存储对象数据的地方而已。

所以我认为，从数据库为主线的系统设计，是有弊端的，重点应该是业务逻辑层的面向对象的设计。但数据库设计也并非不重要，它的表结构的优化，性能的优化，应该在整个软件的生命周期内，持续地进行。