所有的业务系统都是在做数据的维护和读取

在CSDN上读了一文《数据库时代的终结意味着什么？》，不大赞同作者的观点，我的观点如下：

信息时代，信息就是数据，数据也是信息，谁包含谁我不想咬文嚼字。我的观点如题：所有的业务系统都是在做数据的维护和读取。

数据库管理系统开发工作近8年，总结我的90%的工作内容都只有四个SQL语句：Select,Insert,Update,Delete。Select用的最多，因为所有的数据及各种统计分析报表最终目的是要人或程序来读取的。

当然这是一个概括，Select是我对所有SQL查询，包括复合查询，各种统计分析报表和商业智能分析结果的一个总称。其它数据库设计与管理工作都是对能更好的得到这个Select结果，我把这种结果称为最终视图，不同的用户需要不同的视图，视图内容又是随着时间随时变化的，可能只是看一眼，也可能要打印出来，还可能由程序读取或再做其它处理，如银行转账，存款取款等等。

数据库管理系统的开发就如“卖油翁”，无他，其实就是做数据的维护和读取。

今年就30岁了，三十而立，程序人生不尽如人意，我以后要专注于做一个数据库管理员，DBA才是我的兴趣和理想。

完了，再向大家拜一个晚年，新年工作顺利，万事如意，牛年，你我都牛起来。

 

(内容可能有些笼统和单调，将后面我的回贴加到下面丰富一下）

 

---

 

#13楼 回贴

 

下班前写完的，没想到这么多人关注，谢谢大家这么捧场哈，新年头一天，并不是想哗众取宠，只想发表一点点个人的见解，相互探讨。

公说公有理，婆说婆有理，站的角度不同，结论当然也不一样，我的观点也只想说明数据库存储，结构设计，数据存取，性能优化是一个应用系统的重心，当然不一定非是关系数据库，但毕竟我们日常99%都在用RDBMS和SQL。这也是我个人的兴趣和发展方向。

我现在的工作也是软件开发，从这个角度出发应该把企业业务逻辑做为中心，但同时我也负责数据库设计甚至大部分DBA的工作，象我这样的同学也不少吧。我的开发步骤就是先根据企业业务逻辑流程设计数据库结构，然后再写中间业务层，最后写B/S或C/S的用户界面。我没有按测试驱动开发，数据库设计似乎在测试驱动开发中只字不提，或者根本就不是开发员的工作范围。

我研究过K3/Agile/OracleEBS等大型系统的关系数据库设计，95%的界面操作都不是对单个表的Select/Insert/Update/Delete，有非常多的企业业务逻辑不是在中间业务层或者应用程序代码中实现的，而是在存储过程/SQL函数/解发器中实现的，经常在一个数据库事务中包含对几个甚至一二十个表的操作。所以，我才得出了这篇文章的观点：数据库存储，结构设计，数据存取，性能优化是一个应用系统的重心或中心。

这里又有一个引申议题，中间业务层是不是一定要在程序代码中实现，还是可以在数据库的存储过程/SQL函数/解发器中实现呢，答案决不会是只选前者，存储过程实现业务逻辑也有非常大的性能优势，但缺点可能是难以管理维护。

故大型系统的设计，部分中间业务层仍然包含在数据库中，不信可以看一下K3/OracleEBS，SAP估计也不例外，银行/电信系统更不用说，虽然后两者我没接触过，谁说数据库不重要呢。我曾做过一个计算BomCost的系统，完全用MSSQL存储过程/函数/触发器设计，定期计算生成所有BOM的Cost，最终用Access项目直接连接MSSQL展现数据，没有用其它任何语言或工具开发。
我是不是又说了一堆废话呵，^_^，睡觉去了。

 

#15楼 回贴

金色海洋说的对，归根结底还是面向对象的数据库太不成熟，没有广泛应用的商业面向对象数据库，所以我辈中人99%都使用RDBMS，而喜欢面向对象的同学就只好使用别人设计好的ORM架构了，

Oracle/DB2/SQL SERVER等数据库管理系统现在都宣称可以实现面向对象的数据存取，但试问，我们国内的软件开发过程中实际应用有几何，不足1%吧？。

我很少使用Java，恕我理解肤浅，Java仅仅是一种编程语言，只不过市场上有许多第三方组织用Java写的ORM框架而已；同理C#也是一种编程语言，LINQ也是一种ORM框架而已。编程语言和数据库存取有着紧密的关系，但完全是两个概念，谈何替代。