|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-24
http://forum.iteye.com/viewtopic.php?t=7424&start=30
robbin 写道 其实我看到的现状就是现存的基于数据库系统已经非常脆弱了，这种脆弱指的是可维护性，可扩展性。除了某几个特别熟悉的人之外，其他人都不敢去动，而这个人一旦休假，整个系统就瘫痪。我见过有3个公司都是这种情况了。
potian 写道 robbin讲的情况是非常普遍的，我基本上可以断定一个业务逻辑比较复杂的系统全部实现在数据库中（或SQL语句中）加上TS的做法是非常难以重用的
一般公司里面只有1-2个人才敢改，系统越庞大，感改的人就越少，改了以后也是心惊胆战的，这种系统我看到得实在太多了 potian 写道 银行的遗留系统用的都是这种方式，并且OO的开发成本在早期来看是相对较高的（你需要比存储过程更多的抽象模型）
想起一个故事，我大约在三年前去一个公司做技术负责，当时有一个项目已经运行了1年左右，但是不断的修改导致原先的业务出现了很多问题，大家都觉得头都大了，该了这里，那边出问题，改了那里，这边出了问题，原先写存储过程的人有几个也不再了，结果大家对着一系列中间表和表里面很多莫名其妙的标志发呆，拿来原先的设计文档和数据词典一看，很多都对不上。而存储过程代码本身的表达能力又非常有限，很少有抽象、一致的概念。例如，标志其实使用来代替OO子类的，中间表常常用来表达对象之间的复杂关系等等。业务逻辑实现通常是单片的过程代码，而无法用揭示意图的可覆盖的方法来表示。 我看了原先的系统后发现居然每一个业务，不管简单还是复杂全部都是用存储过程实现的，分析他们的业务以后，我提出基本上不需要几个存储过程，结果把项目经理吓了一跳，没有存储过程怎么写程序？ 实际上我看到过的系统有非常多的是用这种方法实现的，不管是银行系统、ERPx系统、公安系统，而实际上正是这些系统才比一般的系统具有更加复杂的逻辑，才有更大的规模，才是OO大展身手的地方，可惜由于从业人员的水平（她们的业务水平比较高，因此在技术上也有了相对多的说话权）、传统系统的遗留和OO早期的复杂性导致了正是这些系统在国内处于较低的技术水平。 |
| 返回顶楼 | |
|
发表时间：2004-09-24
thor0127 写道 老大们，你们谁见过业务有了变化，而相对应的数据结构没有变化的。
就我的经验来说，我认为把业务逻辑用SP来实现比较可靠，稳定。 在说SP的移植是很容易的。说SP的移植是困难的是因为他没有把所有的业务想清楚了。 联通的手机话费优惠策略三天一小变五天一大变，莫非他们天天在那改数据库不成？ |
| 返回顶楼 | |
|
发表时间：2004-09-24
robbin 写道 http://forum.iteye.com/viewtopic.php?t=7424&start=30
觉得这是管理问题，很难说再过几年某些用o/r的公司不会出现这样的问题。 从根本上说是企业急功近利所导致的局面，可能先天的特性导致sp和o/r出现问题的程度不同，而且由于sp更符合急功近利的要求，所以会成为首选。 |
| 返回顶楼 | |
|
发表时间：2004-09-24
thor0127 写道 老大们，你们谁见过业务有了变化，而相对应的数据结构没有变化的。
就我的经验来说，我认为把业务逻辑用SP来实现比较可靠，稳定。 在说SP的移植是很容易的。说SP的移植是困难的是因为他没有把所有的业务想清楚了。 真的是我们没有把业务想清楚吗？不单单这个问题吧。我就拿sql server 2000 与它的7.0来移植好了（sql server 2000向sql server 7.0移植)，你都不能保证100%，更何况移植到其它的数据库。 如果不是因为性能问题，我一般都不愿意用sp。 还有就是一个问题每个数据库的sp的语法都不大相同，这也是学习的成本呀。 orm我觉得有一个很大的好处就是它对不同的数据库都是相同的操作，当然orm有它不能处理的地方。 还是上面很多人的意见，orm vs sp本来就是不能比较的。 |
| 返回顶楼 | |
|
发表时间：2004-09-24
其实stored proc和OR mapper配合使用是一个很好的方案， 用sp来做select效率很高， 比如在oracle里， 有一种cost-saving paradigm，当sp在第一次运行后被parse, 他的execuation plan和PL/SQL cursor 被保存在LRU cache里， 后面再运行就会很快， 即使你用Dbms_Sql.Close_Cursor去close他， 这些对象也不会马上消失，这叫'soft close', soft close不会造成maximum open cursors问题， 但dynamic sql就不可以，当你close他的cursor, 他所有的depended对象就没了， 你不close, 很快就得到maximum open cursors error.
我们一般对一个binsines object写几个sp来做query, 比如get_book_by_id, 或list_book, 用DAO把他们对应起来， 如果是有aggregate， 一个sp返回的结果会分散到几个object collection里。 而BO的insert, update, delete,都用OR mapper动态生成sql来做， 而且支持partition table， 比如动态生成的insert sql是INSERT INTO table_name PARTITION_name (..) values (..), 另外还支持用bulk insert, 或direct path insert.只要改一下or mapper的参数就可以了 |
| 返回顶楼 | |
|
发表时间：2004-09-24
HQL用来做查询还不错，但是对于批量数据的更新，删除，用Hibernate恐怕不太经济吧。
Hibernate In Action里面 , Gavin King也说过，如果有大量数据的变更的场合，很可能根本就不应该使用ORM的解决方案。 |
| 返回顶楼 | |
|
发表时间：2004-09-24
ERP里面比较复杂的排程和诸如电信行业的价格、大医院的排班等等在国外早就采用规则引擎来做了，OO的灵活性和能力都不够，更不要说数据库的存储过程能够适应复杂的变化，Ilog号称几个比较大的公司用的都是他们的规则引擎。不用规则引擎至少也得用策略模式，免得价格政策一边还要去修改原先的代码。
简单的诸如组织机构，帐务规则等等，分析模式出版都7、8年了，分析模式里面的模型，用存储过程实现起来何等复杂，并且根本达不到不改变原先的代码就可以扩展。绝大多数应用程序，这点效率上的差异根本不在乎，你在乎的是系统的可扩展性和可维护性。 真正在乎效率的场合又绝大多数是非常快的插入、更新操作，但一般没有什么复杂逻辑需要执行，又涉及到某些需要即时统计的东西（如果光是插入，根本就无所谓）或者是要做批量操作，这些地方是可以用存储过程来实现的。而即使是一个对效率要求非常高的系统，程序这样的部分也是不多的。（一般来说就是快速的前台录入、复杂的报表数据生成和夜审、结算这几部分）。而对于系统的绝大部分，效率都不是关键问题。 一般来说，一个业务越复杂的系统,O/Rmapping使用的场合就越多，而在对性能要求特别高或者批量数据处理特别大的地方，我们可以适当调整为存储过程。 使用了O/RMapping的作用不是为了ORM而ORM，而是为了填补那个裂缝，从而我们可以比较自由地运用OO的所有优点，还可以自由集成规则引擎等等各种各样的机制来实现业务本身，这些东西存储过程根本就是无能为力。 |
| 返回顶楼 | |
|
发表时间：2004-09-25
gigix 写道 thor0127 写道 老大们，你们谁见过业务有了变化，而相对应的数据结构没有变化的。
就我的经验来说，我认为把业务逻辑用SP来实现比较可靠，稳定。 在说SP的移植是很容易的。说SP的移植是困难的是因为他没有把所有的业务想清楚了。 联通的手机话费优惠策略三天一小变五天一大变，莫非他们天天在那改数据库不成？ 这种优惠往往是在库外做的，库内只是放配置表，优惠都是在库外用c或者c++实现的。一般的移动联通的系统，在这几年，除了报表和营帐的一些业务，大部分 都需要在库外做，数据库压力太大了，而且很慢，至于说道sp的移植，那困难太 大了，特别是大的数据库，表上千个，sp上千个，你去移植吧，谁也不敢动，出了事，没有人来扛的。 |
| 返回顶楼 | |
|
发表时间：2004-09-25
sankxuan 写道 gigix 写道 thor0127 写道 老大们，你们谁见过业务有了变化，而相对应的数据结构没有变化的。
就我的经验来说，我认为把业务逻辑用SP来实现比较可靠，稳定。 在说SP的移植是很容易的。说SP的移植是困难的是因为他没有把所有的业务想清楚了。 联通的手机话费优惠策略三天一小变五天一大变，莫非他们天天在那改数据库不成？ 这种优惠往往是在库外做的，库内只是放配置表，优惠都是在库外用c或者c++实现的。一般的移动联通的系统，在这几年，除了报表和营帐的一些业务，大部分 都需要在库外做，数据库压力太大了，而且很慢 所以说了，OLTP的业务逻辑还是应该在OO程序中完成，一则自然，二则灵活。 |
| 返回顶楼 | |
|
发表时间：2004-11-01
这个问题我也想好久乐，目前只能是选择团队熟悉的解决方案。
啊，什么时候无招胜有招就ok乐。 |
| 返回顶楼 | |
