工作中一直不喜欢数据库编程，也要求团队中尽量不要用存储过程和触发器，除非真的能带来很多好处。实话说，我写的存储过程代码一般不超过10行，且与业务无关，触发器就更不说了。但最近看到一些问题，有感而发。不对之处请指教（原想写长点，但水平不行，就写个标题算了）。
一．不能进行版本控制（印象中Ms Sql的好像可以加到vss，其他数据库不知道）
因为不能版本控制，所以就怕代码丢失和回滚。为了保存回滚信息，故有大段的注释的旧代码，有时旧代码量超过了实际代码，也没人删除。更不能保证多人编辑时的同步问题。
二．不能统一代码管理（代码备份）
有点规模的开发过程，都要求有代码管理系统，如vss。但这数据库中的这部分代码却在vss之外，需要单独的管理。也许可以加到vss中去，但也不太方便。
三．编程不便，
1． 错误处理、流程控制、数据类型等，都和现代的编程语言（如C#）差的太远。比如字符串处理不灵活，不支持集合等。看到有人为了复杂循环而大量使用游标，而在dotNet中记录（DataRow）是数组存放的，想怎么定位修改都行。
2． C#是面向对象的，写出来的代码相对要优雅，多点代码也容易懂，对象间的调用也易理解；而存储过程中代码多了就不好玩了，存储过程嵌套调用也好不到哪去。
四．调试不便
虽说现在的存储过程也可以单步调试，但调试一般是应用程序发起的，再跟踪到存储过程，两处调试终归不便。
五．错误隐藏
1． 触发器对不了解系统的维护人员，会造成找不到北的错误，永远也不知错在哪，最后才发现是一条触发器惹的祸。
2． 大而复杂的存储过程，也让人头大。见过上千行的存储过程，也许程序员开始并未想到写这么长，只是后来越改越长，控制不往了。