探讨用存储过程的优劣

很赞同

使用存储过程的优点：
1.开发速度非常快，基本上一个增删改查一个小时就能搞定
2.可以实时的更新业务逻辑代码不需要重新编译java代码，对于业务逻辑经常变的系统这点很有帮助
缺点：
1.数据量大时，对数据库的压力就非常大
2.对于热门资源访问量较大，容易形成堵塞，若存储过程写的不好，容易产生死锁。web层可以很容易无限的横向扩展，但数据库就只有一个，一但数据库堵塞了，整个系统也就差不多要挂掉了。使用存储过程会增加数据库服务器的负担。

我们公司就是将业务都写在存储过程里，现在经常都会堵塞，快要下班时系统就很慢。我们想了很多办法，将使用非常频繁且对数据库有压力的查询使用Lucene来完成。页面静态化，减少用户对数据库的访问。现在数据库的压力还是无法释放，正考虑换sql server2008,能将数据库的内存加到12G,可以缓解一点数据库的压力。

曾经写过很长一段时间的oracle的存储过程，还是那句话，看场景很重要，over

说的在理，隐式类型转换是一个很容易让人掉入的陷阱。还是那句话，编码规范和注释很重要，可以很大程度避免类似问题隐藏在程序里。当然了，检查新手写的程序也是不可缺少的一环，多教几次，此类问题可以避免。

1、如果你们有非常频繁的查询，建议采用缓存架构，可以很大程度上缓解数据库的压力
2、没有采用集群吗？数据库也可以横向扩展，并且你可以读写分开。
3、读写分开+缓存架构，我觉得基本上能适应大多数的场景。

你们是什么样的业务？具体能探讨一下吗？

看具体场景，有时候哪怕你不同意：）

我们的业务对实时性要求很强，比如说客户资料的录入，录入之后一定要马上可以查找到，否则会出现相同的客户。所以读写分离是没有办法，这点我们也有考虑过，因为对实时性要求的高，所以没有使用缓存。
至于集群，只要是需要钱去买sql server的服务，老板就不批。所以现在数据库的横向扩展一直都没有做。
现在只是在做分表，希望尽量可以将表的记录减少，还有将历史数据放入历史表，定时的将数据搬迁除去。但有些大表根本不允许将数据搬迁除去。分区暂时还没有做。

你说“客户资料的录入，录入之后一定要马上可以查找到”，这个客户资料的录入，是很普通的一个操作，并不会造成数据库压力，这部分不需要读写分离。

但是，你可以把单条客户资料放入缓存--假设终端要频繁访问客户资料的话。比如你有100万条客户数据，可以都放入缓存。系统性能会提高，数据库压力会减小，特别是如果有大字段操作的话性能提高更明显。

历史数据迁移，这个是肯定要做的，否则系统必然越来越慢。

比如说customer表，我们有一个功能使用的非常频繁，这个功能有20来个查询条件，而且还有需要使用对大字段使用like,当然like部分已经用Lucene实现了。都放入缓存中，可是需要查询customer表中的记录怎么办呢？
查询字段：客户编码，关键字1，关键字2，电话号码，邮件地址，手机号码，区号，客户地址还有很多字段为查询条件。

我都说不谈性能了...
真要较真那还真得看应用场景，系统吞吐量。举个极端的例子，Google search这种应用你再编译再优化也不是数据库自己能搞定的。
适合SP是那种牵涉到大量数据操作的过程，比如从几百万数据中按某种规则反复进行匹配查找，SP占了和数据库内核在一个内存空间的便宜，当然比通过网络来回传快的多。 但对数据不多规则却非常复杂的操作，明显是Java更方便一点。 什么预编译啊优化啊都是浮云，DB有JVM也有，不是决定性的因素。