|
锁定老帖子 主题：探讨用存储过程的优劣
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-01-19
xiaoshan5634 写道 使用存储过程的优点：
1.开发速度非常快，基本上一个增删改查一个小时就能搞定 2.可以实时的更新业务逻辑代码不需要重新编译java代码，对于业务逻辑经常变的系统这点很有帮助 缺点： 1.数据量大时，对数据库的压力就非常大 2.对于热门资源访问量较大，容易形成堵塞，若存储过程写的不好，容易产生死锁。web层可以很容易无限的横向扩展，但数据库就只有一个，一但数据库堵塞了，整个系统也就差不多要挂掉了。使用存储过程会增加数据库服务器的负担。 我们公司就是将业务都写在存储过程里，现在经常都会堵塞，快要下班时系统就很慢。我们想了很多办法，将使用非常频繁且对数据库有压力的查询使用Lucene来完成。页面静态化，减少用户对数据库的访问。现在数据库的压力还是无法释放，正考虑换sql server2008,能将数据库的内存加到12G,可以缓解一点数据库的压力。 +1 其实SP还有一个很重要的功能：统一API。有时候一个数据库不仅仅就一个应用在操作，例如一个系统，它有web平台（Java），也有本地的CS平台（.NET）。这个时候就可以使用SP统一API。 当然，这种情景，你甚至可以用上一些中间件，例如ICE之类的。 SP有一个比较明显的缺点：部署的时候的版本控制比较麻烦。 |
| 返回顶楼 | |
|
发表时间：2011-01-19
魔力猫咪 写道 为什么这么多人都认为Java代码不如存储过程好调试测试呢？单元测试和断点调试怎么着都是Java代码好调呀。
有时候单元测试调不鸟的时候，你不得不启动一个容器，更有的系统代码是依赖于某个容器自身代码的实现，比如weblogic之类的，让它慢慢启动吧，它再会自动加载，也会有死一次的时候 |
| 返回顶楼 | |
|
发表时间：2011-01-19
老生常谈了 以前我也跟LZ一样困惑，但想来LZ是没有弄过多机存储吧，或者说sharding，缓存这些。真用到了，你就会觉得存储过程相当无力
|
| 返回顶楼 | |
|
发表时间：2011-01-19
glovebx 写道 好吧，我承认没看过说明，一直以来都当他是免费的，至少5.5以下还是免费的吧？ 自动的单元测试没做过：），白盒+黑盒测试过了，再有就是用户边用边改。 BUG不多，主要是数据计算错误--涉及的表比较多不小心就漏了，或者漏了个字段。 是否免费和版本没有关系。我记得好像是开源软件或者运营的网站是免费的，闭源的商业软件是要收费的，而且价格不菲。很多开发人员误认为MySQL是无条件免费的了。 没有单元测试，边用边改，回归测试能累死你，否则会改了一个问题又带出n个，除非你的业务很简单。目前我们有一个项目就陷入越改问题越多的困境。 |
| 返回顶楼 | |
|
发表时间：2011-01-20
liangguanhui 写道 xiaoshan5634 写道 使用存储过程的优点：
1.开发速度非常快，基本上一个增删改查一个小时就能搞定 2.可以实时的更新业务逻辑代码不需要重新编译java代码，对于业务逻辑经常变的系统这点很有帮助 缺点： 1.数据量大时，对数据库的压力就非常大 2.对于热门资源访问量较大，容易形成堵塞，若存储过程写的不好，容易产生死锁。web层可以很容易无限的横向扩展，但数据库就只有一个，一但数据库堵塞了，整个系统也就差不多要挂掉了。使用存储过程会增加数据库服务器的负担。 我们公司就是将业务都写在存储过程里，现在经常都会堵塞，快要下班时系统就很慢。我们想了很多办法，将使用非常频繁且对数据库有压力的查询使用Lucene来完成。页面静态化，减少用户对数据库的访问。现在数据库的压力还是无法释放，正考虑换sql server2008,能将数据库的内存加到12G,可以缓解一点数据库的压力。 +1 其实SP还有一个很重要的功能：统一API。有时候一个数据库不仅仅就一个应用在操作，例如一个系统，它有web平台（Java），也有本地的CS平台（.NET）。这个时候就可以使用SP统一API。 当然，这种情景，你甚至可以用上一些中间件，例如ICE之类的。 SP有一个比较明显的缺点：部署的时候的版本控制比较麻烦。 完全同意你的观点，版本控制确实比较麻烦，现在我们是每次修改完成的时候都保存为文件，然后将其上传都SVN,这样就人为的做到了版本控制。 |
| 返回顶楼 | |
|
发表时间：2011-01-20
glovebx 写道 xiaoshan5634 写道 glovebx 写道 xiaoshan5634 写道 比如说customer表，我们有一个功能使用的非常频繁，这个功能有20来个查询条件，而且还有需要使用对大字段使用like,当然like部分已经用Lucene实现了。都放入缓存中，可是需要查询customer表中的记录怎么办呢？
查询字段：客户编码，关键字1，关键字2，电话号码，邮件地址，手机号码，区号，客户地址还有很多字段为查询条件。 读写分离，为此部分查询提供只读数据。这样主系统的压力就会减小。 客户编码等这些检索字段，尽可能短，尽量固定长度（比如用char类型），建索引。Lucene不是很熟，但是我看过有人用Sphinx结合mysql做的全文搜索，看上去性能不错。 开会了，回头继续探讨。 Sphinx结合mysql做全文搜索，建索引的速度比Lucene快很多，但他只支持utf-8，了对中文的支持不是很好，它还有一个弊端就是一定要跟mysql结合使用，现在我们使用db4o+Lucene，而主数据库用sql server。Sphinx一定要结合mysql,所以要换的话还是由点麻烦的。 你们是sql server，那就没办法了。 换数据库也不现实。 这么多条件的查询，有没有什么好的缓存解决方案？谁有过经验的给介绍介绍 是啊。。 有好的缓存解决方案请给介绍介绍，有好的经验解决这种问题也请介绍介绍。 |
| 返回顶楼 | |
|
发表时间：2011-01-20
把业务逻辑写到存储过程，是种很不好的实现方式。因为一般随着业务的增大，逻辑的复杂，性能会逐渐下降，后面你会发现MySQL已经无法满足你的需求，得换Oracle或者SQLServer， 或者做一些迁移，集群之类的，一般需要改变的都是数据库，而不是前端或者服务器Java代码，这样你那些写在数据库里面的东西都得改，数据库写的越多，工作量越大。
|
| 返回顶楼 | |
|
发表时间：2011-01-20
最后修改：2011-01-20
sniffer123 写道 老生常谈了 以前我也跟LZ一样困惑，但想来LZ是没有弄过多机存储吧，或者说sharding，缓存这些。真用到了，你就会觉得存储过程相当无力
sharding并非任何时候都需要考虑，缓存我们现在就有。 如果仅关注一个点，说存储过程相当无力，没有说服力。 我们现在的方案，某些数据如果有更新，在存储过程里通过udf将json格式的数据直接写入tokyo cabinet的缓存里。前台取数据的时候先看缓存，没有则从数据库取。 |
| 返回顶楼 | |
|
发表时间：2011-01-20
最后修改：2011-01-20
seya 写道 把业务逻辑写到存储过程，是种很不好的实现方式。因为一般随着业务的增大，逻辑的复杂，性能会逐渐下降，后面你会发现MySQL已经无法满足你的需求，得换Oracle或者SQLServer， 或者做一些迁移，集群之类的，一般需要改变的都是数据库，而不是前端或者服务器Java代码，这样你那些写在数据库里面的东西都得改，数据库写的越多，工作量越大。
写在代码里，同样会有“一般随着业务的增大，逻辑的复杂，性能会逐渐下降”的问题。 我不觉得SQLServer的性能强过mysql，mysql支撑千万级的海量数据一点问题都没有。 另外，选型的时候这些都考虑过，就进销存而言，mysql足够了，不存在换数据库问题。 换数据库带来的修改工作量确实非常大，所以任何项目技术选型要慎重。 另外，如果业务逻辑都在java代码里，那么后面如果有业务变更--特别流程变更时，你会发现改代码成了噩梦，牵一发而动全身。sp对付这样的修改就容易得多--个人经验谈。 |
| 返回顶楼 | |
|
发表时间：2011-01-20
这个问题很简单-----------------答案是：绝对不能用 |
| 返回顶楼 | |
