我想，程序员对数据库应该相当敏感的词语。并且对于词语“数据库作为编程的基础”应该是相当的认同。我原来也这样认为。并且极力的推崇采用存储过程的方式来完成程序的书写。

   去年我们公司购进了一个系统，并与我们开发的系统组合到一起。在这个系统里面。我学习了一下他们的设计方式。总体来说是高度依赖数据库。并且许多业务逻辑都封装在数据库里面。大量采用触发器来完成数据的搬移等工作。在里面书写一个函数几百行那是很正常的。

   而我做个第一个项目是极少采用存储过程。这个项目也不是很小。当时的设计规格是和中华英才的招聘项目的规格。但是在这个系统里面就只有几个Helper 。业务逻辑完全存在于页面的CS代码里面。当时发觉有一个好处速度嗖嗖嗖的快。后来维护和新系统添加的时候就发觉问题了。

   要对外扩展一个功能。就一个webserverce。或则就直接数据库面直接都令一个数据的表。完全是在做手工敲打。在高度机械化的时代，我感觉到了刀耕火种。

  总的来说，当时的设计就是高度依赖数据库。并且数据库决定了业务逻辑。并且根本没有三层架构，只能算是刀耕火种的两层模式。我后来发现了一个很好听的名字来灌输给他－－“事务脚本”设计模式。

  我不能完全的否认这样的操作好不好。我个人观点，这样的模式好在开发的程序效率。但是在维护方面以及某些性能优化方面可能做不到。因为，一个按钮一段业务逻辑代码。最后的效果是新的业务逻辑又要新的代码。完全不能重用。

  话说回来，数据库好不 好的问题。数据库好。并且很好。关键是看你怎么看待他。我意思是我们应该驾驭数据库不是什么业务逻辑都高度依赖数据库。一个功能对应一个存储过程好吗？我个人观点是不好。原因很简单---这样做只会增加程序的难以维护。如果数据库类型发生修改，你可能做的事情更多。但是我绝没有说不能使用存储过程。因为他的优势还是很多的。特别是在效率方面。只是不能滥用他。

   数据库的本质工作，我的个人理解就是作为保存和管理数据的地方。他不存在是作为系统的基础。简单道理。同样存储数据即可以是数据库，又可以是文本文件，还可以是其他的方式。而数据库有其强大的地方在于，他有很好的数据管理机制。他除了保存数据之外还有数据管理的功能。所以我们要使用他。然后某些时候我们还是可以使用最原始的文本文件的功能。比如：图片的管理等。多媒体的管理。

   而在我们开发之中，时常有客户需求或则架构师的设计发生了错误等状况，我们必然要修改数据库的表。我认为很正常，即便如此我也不觉得他是基础。我觉得设计架构才是基础。架构设计直接决定了系统的数据库设计。而他是低于数据库的阶段。

   即时客户的需求发生了变化，我们可以在ORM的阶段或则BILL的阶段来做局部的消化。但是绝对不是是说非要把数据库的表发生变化。

  而我比较喜欢的设计模式是从需求到数据库的设计。而也不是从数据库向上设计。而我更喜欢领域模型做为重点的设计地方。Bill的设计也是重点。

 

   这就是我的对数据库的看法。数据库只是存储和管理数据的地方。他绝对不是程序的主。

     说是架构师不如说是程序员，我们公司有一个架构师其实本质就是程序员。在团队里面无威信力。没有正确领导的本事。作出规定，我们都不给予采纳。这样的架构师算得架构师吗？我想在我们团队里面都会觉得不算得。

     而我们团队是小小型团队，连架构师在内只有5个程序员，这样的团队有必要要架构师吗？各位兄弟怎么看待这样的鸟枪团队。而这鸟枪团队还要做几个大型网站以及一系列的桌面应用程序。这个团队不是专家团队。大家认为是否可以撤销这个架构师。而采用大家讨论的方式来解决问题。