OO和面向过程的SQL

     前段时间回顾开发的一个项目，发现一些问题，使我对面向对象的应用有了新的理解。     先介绍一下这个项目，该系统主要是基于第三方系统的业务数据进行统计、分析和预警。这些业务数据实体较多、实体间关系复杂，并且有的实体表里的记录达到千万级别。

     其中一个功能需要将A表里符合一定条件的记录进行聚集操作，然后将B表里也做聚集操作，最后把A、B表聚集的结果通过某字段连接起来（实际情况比这个复杂）。一开始考虑使用面向对象来设计，把各个记录映射成实体类，然后对实体类进行统计操作，结果敲键盘码了几百行代码，而且测试起来性能也较令人担忧。最后实在受不了了，放弃一切皆OO的理念，使用了面向过程的存储过程，类似于select * from (select max(A.b),A.a from A group by A.a) Q left join (select max(B.n),B.m from B group by B.m) W on Q.a=W.m的sql。开发效率和性能一下就上去了，这类统计逻辑的实现基本全放弃OO，采用sql的方法解决。

     对这种情况，一开始感到困惑，为什么OO在这样场景的使用这样被动，OO不是告诉我们了表达和描述客观世界的办法了吗。后来查阅了大量的资料，进行了自己的思考：OO描述的是相互作用的事物的世界，最擅长于描述客观存在的人和物以及它们间相互操作的关系，这使得其在复杂多变的、多实体交互的流程逻辑上显得游刃有余，充分体现了其可维护性、复用性、可扩展性上。而在以数据库为主体，且包含了许多计算复杂度高功能的信息管理项目上，该领域对应的是一个面向关系的世界，表和表间的关系就是直接的、稳定的业务关系，在这种项目中使用多余的对象映射就会导致实现复杂度提高，OO的劣势大于其优势。

     所以，在不同的场景，应该做出适当的选择。OO也仅仅是解决方案的一种构思方式。虽然适合大多数情况，但不要唯OO是瞻，过分的放大OO的优点，而忽略其不足的地方。