CTO要求把所有逻辑放到数据库合理吗？
CTO提的，照做就是了，不用考虑是否合理。谁提的谁背锅。
实际上我毕业后的第一份工作，所在的公司，就是所有业务写在数据库存储过程中的。而团队中也专门有负责写存储过程的研发工程师。这部分工程师可以拿比C/C++工程师更低的薪水，毕竟写SQL比写C/C++简单多了。而且跟我一波进去的人，学习存储过程的编写，比我这边学习服务器后端C/C++开发，上手快多了。几个月后，搞存储过程那波人几乎个个能独当一面，我这边可能只有我的C/C++服务器后端技术磨合起来了，其它几个因为不能胜任而转岗。
至于结果如何？我只能告诉大家，这个公司现在是500强。
我的意思是，我认识现实中的案例证明这么做是可行的，而且我没发现哪个公司因为这么做而倒闭的。所以我觉得这个行为没有啥不合理的地方。
如果你就是觉得数据不该跟逻辑放到一起，那么把存储过程的数据库跟存储数据的数据库分开就行。存储过程在逻辑数据库中运行，然后再备份同步到数据存储数据库中去。
业务逻辑跟界面或者前端分开，本来就是很合理的做法。在客户端盛行的年代，要求逻辑写进数据库基本等同于要求界面与逻辑分离，很合理的要求，不是么？
至于写SQL跟写其他语言，其实也没有太大的本质区别，相关的该有的工具也都可以有，只不过很多人没接触过罢了。而一个公司既然决定启用这样的技术栈，自然就有相关的技术解决方案，调试SQL自然也不是问题。
究竟有什么强有力的理由认为这样做不合理？我觉得没有。
