|
锁定老帖子 主题：探讨用存储过程的优劣
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-01-19
glovebx 写道 问题是作为一个产品，考虑成本等各种因素还是采用MySQL。Linux/MySQL/Tokyo Cabinet，性能还行。 显然python、Ruby等开发效率更快，奈何没有这个人手啊，完全没时间学习。 你用MYSQL并不一定节省成本，要看你的运营模式，这点你要仔细看看MySQL的许可说明，一般来说你是要掏钱的 
glovebx 写道 忘了说了，我们前端是Flex，所以在传统mvc架构中本应该在java端(controller)的处理逻辑（比如页面跳转等）都交给了前端，所以现在java端的代码非常简单。 业务逻辑分布在了数据库和表现层，你的单元测试肯定很难做。 |
| 返回顶楼 | |
|
发表时间：2011-01-19
sunliao_first 写道 flex的速度远比不上html，html的前端效果现在做得也是不错的
就这个话题来说，还是技术选型的问题。 事实上，我们以前做过足浴系统的管理软件，你都无法相信里面的js代码有多长，有多难维护。而且为了压缩页面文件大小，注释非常稀少，一有改动就很耗精力和时间。 作为进销存这样的系统，flex要比html适合很多。效果如何并不非常重要，界面操作性、软件易用性以及可维护性，html都是比不上flex。 |
| 返回顶楼 | |
|
发表时间：2011-01-19
BigBlue 写道 glovebx 写道 问题是作为一个产品，考虑成本等各种因素还是采用MySQL。Linux/MySQL/Tokyo Cabinet，性能还行。 显然python、Ruby等开发效率更快，奈何没有这个人手啊，完全没时间学习。 你用MYSQL并不一定节省成本，要看你的运营模式，这点你要仔细看看MySQL的许可说明，一般来说你是要掏钱的
glovebx 写道 忘了说了，我们前端是Flex，所以在传统mvc架构中本应该在java端(controller)的处理逻辑（比如页面跳转等）都交给了前端，所以现在java端的代码非常简单。 业务逻辑分布在了数据库和表现层，你的单元测试肯定很难做。 好吧，我承认没看过说明，一直以来都当他是免费的，至少5.5以下还是免费的吧？ 自动的单元测试没做过：），白盒+黑盒测试过了，再有就是用户边用边改。 BUG不多，主要是数据计算错误--涉及的表比较多不小心就漏了，或者漏了个字段。 |
| 返回顶楼 | |
|
发表时间：2011-01-19
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-19
ray_linn 写道 存储过程的缺点就是对开发人员要求比较高，---你们家就叫菜鸟上？那堪虑啊
可能个人局限所见吧，我还真没觉得存储过程对开发人员要求比较高 |
| 返回顶楼 | |
|
发表时间：2011-01-19
ray_linn 写道 govista 写道 我的理解：
1.对于逻辑密集型的业务系统，比如上面提到的进销存，用存储过程的开发效率至少是用JAVA开发的5倍以上，至于说性能，这个和语言的关系不大，关键在对SQL语句的优化。 2.存储过程学习成本很低，新人培训3天可以直接上手，当然，前提是对业务逻辑比较熟练（话说回来，一个对业务逻辑不熟练的人，什么语言高手都不管用）。 3.一行一行敲代码的程序员们，如果要进步快点，可以多花点时间，换换脑子，多理解理解业务吧，别在这讨论这个语言那个语言的。 回看楼主： 高并发下，不知道会不会有问题。完成一个业务过程，牵涉到许多表和好几个存储过程，里面有好几处是FOR UPDATE。设计时已经考虑到死锁问题，所以对多张表的更新顺序是保持一致的。但是高并发情况下会不会有性能问题，目前还未测试。如果有谁有经验，还望不吝赐教。 ---------------------- 这么多不确定能证明存储过程学习成本很低么？ 难道你这些FOR UPDATE，你换成Java就不再需要了吗？要锁的表，用哪种方法还是要锁的…… |
| 返回顶楼 | |
|
发表时间：2011-01-19
glovebx 写道 BigBlue 写道 glovebx 写道 问题是作为一个产品，考虑成本等各种因素还是采用MySQL。Linux/MySQL/Tokyo Cabinet，性能还行。 显然python、Ruby等开发效率更快，奈何没有这个人手啊，完全没时间学习。 你用MYSQL并不一定节省成本，要看你的运营模式，这点你要仔细看看MySQL的许可说明，一般来说你是要掏钱的
glovebx 写道 忘了说了，我们前端是Flex，所以在传统mvc架构中本应该在java端(controller)的处理逻辑（比如页面跳转等）都交给了前端，所以现在java端的代码非常简单。 业务逻辑分布在了数据库和表现层，你的单元测试肯定很难做。 好吧，我承认没看过说明，一直以来都当他是免费的，至少5.5以下还是免费的吧？ 自动的单元测试没做过：），白盒+黑盒测试过了，再有就是用户边用边改。 BUG不多，主要是数据计算错误--涉及的表比较多不小心就漏了，或者漏了个字段。 貌似MySQL商用是要收钱的——很早以前就是。 |
| 返回顶楼 | |
|
发表时间：2011-01-19
liulanghan110 写道 我刚开始工作，只参与过现在这个系统，是JSP页面+STRUTS控制转向+DB2存储过程实现业务逻辑。平时大多数工作就是在写存储过程和改存储过程。系统在在删除、插入操作时，人一多，经常会出现死锁。另外，DB2存储过程调试很不方便，还有，写的好和写的不好的存储过程，可能一个只需要1分钟得到结果，一个需要5分钟得要结果。
最痛苦的就是改别人的存储过程了，特别是那种经过了几个人修改过的存储过程，简直是悲剧。。。 我感觉，一个运行超过三年的系统，去维护它的存储过程，简直是个悲剧。 （1）死锁，跟是否用存储过程问题不大吧？两者应该没有必然的关系。 （2）其实修改次数一多，没有统一coding标准，没有重构，其实无论是SP还是Java还是.net，一样是一件很烦的事情，一样悲剧。 |
| 返回顶楼 | |
|
发表时间：2011-01-19
glovebx 写道 BigBlue 写道 glovebx 写道 问题是作为一个产品，考虑成本等各种因素还是采用MySQL。Linux/MySQL/Tokyo Cabinet，性能还行。 显然python、Ruby等开发效率更快，奈何没有这个人手啊，完全没时间学习。 你用MYSQL并不一定节省成本，要看你的运营模式，这点你要仔细看看MySQL的许可说明，一般来说你是要掏钱的
glovebx 写道 忘了说了，我们前端是Flex，所以在传统mvc架构中本应该在java端(controller)的处理逻辑（比如页面跳转等）都交给了前端，所以现在java端的代码非常简单。 业务逻辑分布在了数据库和表现层，你的单元测试肯定很难做。 好吧，我承认没看过说明，一直以来都当他是免费的，至少5.5以下还是免费的吧？ 自动的单元测试没做过：），白盒+黑盒测试过了，再有就是用户边用边改。 BUG不多，主要是数据计算错误--涉及的表比较多不小心就漏了，或者漏了个字段。 不能自动单元实测，那么就不能说它测试方便。BUG虽然不多（不知道这个不多是什么概念），但是计算不是漏表就是漏字段的，这表明BUG的等级较高，也许数量不多，但是严重程度很大。而在开发的调试和测试中未能及时发现这些BUG，我不知道为什么说调试很方便。 |
| 返回顶楼 | |
|
发表时间：2011-01-19
showtime520 写道 我见过一个新手写SP，用游标来遍历表，然后一条条数据来判断有某个值是否存在这个表里。。。。
个人认为储存过程是要非常熟悉数据库底层的，一些很细节的技术问题菜鸟完全搞不定。我见过最典型的是一个隐式类型转换，表里字段明明是数字，但有些新手就偏偏在where条件里写的是这个字段等于一个字符串。这个问题造成了很多问题。 楼主，祝你好运~~ 难道这个新手换用java，就不会再一个个select出来比较？ |
| 返回顶楼 | |
