数据库存储过程到底该不该用，按照我一贯的编程思想，也就是高内聚、低耦合的编程理念，我觉得像存储过程、触发事件这种东西最好能不用就不用，除非贵公司有一套完整的数据库管理方案，否则可能会遇到不必要的麻烦！
存储过程丢失
上家公司的一个编程能力一般的同事找到我，说代码里面报了一个数据库错误，他没看明白啥意思。我一看，这不就是存储过程不存在的错误嘛！
于是，我就让他找公司DBA去看看数据库有没有这个存储过程，结果他跟我说，这个存储过程在数据库里面没有找到！
因为这里的代码是我写的，他还问我当初调用这个存储过程的时候难道没发现这个错误吗？这问题把我问的，要知道，我离开这家公司都四五年了，过去的事情早忘了！问我当初有没有发现这个错误，我哪知道！
而且，即使当初我写的代码里面调用了这个存储过程，如果有问题其实早就应该发现的，因为报错的代码应该经常被用到才对，如果有问题不会到今天才发现。
还好，最后真相大白了，因为这家公司有很多定制化开发需求，而这些定制化需求都是使用插件式开发动态加载的功能，而软件和数据库是单独部署在客户服务器上的。然后，公司让这个程序员修改这个个性化需求的插件，结果这个插件需要调用存储过程，但公司环境里面没有这个存储过程，所以报错了！
我听说原因以后，以前在这家公司敲代码时的经历就立马涌上了心头，因为类似的事情出现的太多了！
数据库和业务耦合带来的问题
出现问题的首先就是存储过程，其次是表触发事件，然后就是视图。
存储过程出现的问题一般就是找不到，或者每个客户那边部署的数据库存储过程写得都不太一样，导致了程序业务异常。
表触发事件经常会导致死锁，或者因为有些客户那边的表有触发事件有些没有，导致了业务异常。
而视图问题就经常出现了，因为可能每家客户需要的数据都不一样，因此视图写得不一样也很正常，虽然在软件端可以通过配置来选择显示哪些数据，但是如果某个字段在视图里面没有显示，即使软件端配置了也会出问题。
一般来讲，出现上述问题，程序员是必须要去找DBA的，因为我是不负责写数据库的，一般都是由DBA根据客户需求来写的。
当然，正常访问数据库去取数据，程序员还是需要关心一下数据库的。
可是，这家公司的管理数据库的人一般都是薪资比较低的一些计算机专业的人，他们本身就不是那种专门研究数据库的人，因此会闹出很多笑话来。
换个说法，我认为我数据库知识只局限于增删改查，但是他们可能只跟我处在同一水平！这样的人管理数据库，不出问题才怪。
我觉得像存储过程这种东西，本身存在就有问题。因为存储过程代码跟业务是耦合的，这部分的事情完全可以通过代码去做。
尤其是现在动不动就Redis，都是在内存里面操作数据，存储过程就更加没有必要了！
其实往回倒几年，很多关于程序员的招聘要求里面都会要求程序员会写和使用存储过程，但是现在基本上都看不到这种要求了！
尤其是现在ORM框架的流行，直接操作数据库这个事情基本上已经不怎么常见了，就是要做到把代码移到另外一台机器上，不需要手动建立数据库表，代码也能跑！
比如说现在一般都是把表实体放在代码中，加个标记让它在使用时自动建表。
如此一来，程序员能够更加专注于代码实现而不用在意他所不知道的东西。比如我在调用某个存储过程的时候，我还得去看这个存储过程是怎么写的，虽然这样也不麻烦！
或者举个例子，如果数据库表内有个表触发事件，但是程序员不知道，那么可能就会导致意想不到的事情发生，或者代码里和触发事件当中的逻辑重复。
结语
我简单总结下我的思路，您就能大致明白我的意思，我的意思总结一下就是，一个优秀的代码框架应该是就像前后端分离一样，两边各自关心自己的事情就可以了。而代码离开了数据库，不应该受数据库牵制，代码就是代码，数据就是数据，代码负责业务逻辑，而数据库不参与业务逻辑！
热门跟贴