探讨用存储过程的优劣

但很多人的db是不需要scale out，我知道的一些大保险公司的后台db也都是一台。这跟互联网企业不太一样。
我把网络调慢只是为了让网络通信成本显现出来。这是一个非常好的实验设计，没什么囧的。

就算在1000M网络的情况下，多次网络交互的时间在很多时候一样是需要考虑的。
一个是一次双机交互，然后直接N-1次本机。
一个是N次双机交互。

据书评说翻译的很烂，是不是这样的呢？

其实最主要就是看应用场景啦，一杆子打死永远都是错误的想法。
举个例子，你要是微博那样的，用存储过程，那会死得很难看。但如果是OLAP的话，用存储过程比在应用程序端去ORM什么的靠谱得多。

非常的有道理，凡事都有两面性，我们将他的优点发挥出来，尽量规避他的缺点才是王道

为了追求效率与简单化，我也选择将业务逻辑放在存储过程中
较为核心的存储过程由比较熟悉业务的人来处理。
CURD等操作则使用自动化的……

全部用存储过程，等于把业务层也要搬到数据库里，数据库端得承受多大压力啊。

其实最关键的，跨数据库麻烦的很，所有业务sql要重写。整天盯着看一串串的存储过程也挺恶心的。

用悲观锁还是乐观锁跟用Java还是SP是没有直接关系的。简单来说，如果这个锁涉及到到一些长时间的停顿（例如IO、用户操作等），乐观锁比较合适；对于一些back end的批处理数据，悲观锁比较合适。

存储过程的优势不是楼主说的那几点
存储过程的优势在于可以把复杂的数据处理，交给数据库服务做，程序不关心。
项目使用存储过程效果最好的是用DB2或Oracle，因为一旦使用存储过程，必然会使用游标和锁，数据库中处理锁最好的也就是DB2和Oracle了，mysql不清楚，sqlserver里用锁简直是“自杀”。微软不会处理锁。

高并发，取决于你的数据库承载能力，mysql要支持高并发必须进行集群设置，但你用了for update，如没有严格测试，高并发一定会有问题。高并发是for update不仅仅有“争用”，还有不同数据库行级别锁，表级别锁的问题。高并发数据库主要影响因素：锁的级别，数据文件的大小，索引的命中率，数据文件存储的方式，CPU轮转，硬盘I/O等。根据个人经验尽量别用for update。如果有锁的问题，最好采用“表锁”编程方式，比较合适。

同一个业务的业务逻辑不要一部分写到java端，一部分写到sp，如果这样干就相当于拿榔头在维护人员的脑袋。

大部分企业应用的业务层也都是基于数据库的，就算你表面上把逻辑都放在业务层，
最后实际的压力绝大多数一样被直接传导到数据库端。
你想想，你的所谓业务层里边，真正的逻辑计算用时多少，数据库操作用时多少。
基本上，绝大部分时间都是数据库操作用时。


天天考虑换数据库的话，那等于买个Oracle当mysql使了。
我做了这么多年金融核心系统，还没听过换过数据库。
从来就没有人在做系统的时候认为换数据库是一个需要考虑的可选项。

CRUD简单系统换数据库有可能，真正复杂的业务系统换数据库等于自杀。
CRUD的简单系统你本来也没有什么需要用到sp的地方。