偷笑，散分

Question

Delphi版好像很久没有那么“有人气”的帖子了吧...

Answer 1

Harryfin  你光偷笑,但没真相

Answer 2

这是因为CSDN 最火的MSSQL版的不少兄弟让这个贴子火起来的.

Answer 3

Delphi版好像很久没有那么“有人气”的帖子了吧...

Answer 4

是的，MSSQL版的人气让人眼红
不过这个帖被选到网站首页应该是原因之一

Answer 5

to #17：严重建议“肇事者”出来散分 to #24：这就是偶偷笑的原因了，貌似很多论坛都是这类帖子人气最好。不过讨论就好了，非要争出个胜负是没意义了。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－说回正经的，我还真碰上过SQL SERVER转ORACLE的情况。公司以前有个老项目（我来之前做的了），比较典型的RAD开发，数据模块用ADO控件，SQL SERVER存储过程，当然项目是验收了没问题。但是大概1年多后，公司接到了一个同行业项目，想重用老项目的东西。但是这次却要用ORACLE，原因是公司有一套OA开发平台，但是开发平台却只支持ORACLE，不支持SQL SERVER，而我们又跟客户说了我们可以建立一体化的管理方案（就是说不是两套系统）。于是大家应该也看出问题了：1、ORACLE的存储过程是不能象SQL SERVER那样可以直接返回数据集的。想过存储过程结果插入临时表，从临时表SELECT，感觉不是很好；如果想用游标，又要先把数据模版的ADO控件先换掉
2、ADO控件要全部铲掉，换成DOA、ODAC或ZEOS之类（ADO访问ORACLE真的不好）？而且这个项目还真是比较RAD，有个DM上有100多个控件，很壮观。
3、就算技术上解决上面问题了，全部重写存储过程，也要不少时间
4、程序架构测试性很差，难以保证重构后能得到相同结果于是我的结论就是：移植跟推倒的工作量相当。最后公司考虑到成本问题，只好硬着做成了双库的系统（而且是双类型的双库），这已经是给后来的失败埋下了伏笔。其实可能当初谁也没想到后来会出现这么个需求吧。所以一但这样的需求出现，才后悔架构不好，或者用了存储过程，已经晚了。所以我觉得，除非很肯定不会出现数据库变化的了，此时可考虑存储过程；业务不复杂，变化不频繁的，可以考虑用存储过程（可能是我不懂，用SQL SERVER，总觉得抽象业务的能力不足）；否则还是应该考虑下换库的可能性。有作为产品方向的项目，最好考虑下数据层的变化。其实亮剑兄说的关系到决策问题，我还是挺同意的。

Answer 6

关于表扬Delphi版热帖的通告
    ——兼答华仔
http://topic.csdn.net/u/20091218/11/f4f112a0-dc90-45ee-a38b-01f94feff809.html

Answer 7

哈哈 oooO ↘┏━┓ ↙ Oooo 
 ( 踩)→┃你┃ ←(死 ) 
  \ ( →┃√┃ ← ) / 
　 \_)↗┗━┛ ↖(_/ 

Answer 8

人家叫你哈瑞,我也叫你这个吧. 哈哈我们的曾经的一个产品(比较大)．呵呵．至少数据是集群的．　业务逻辑以 Procedure 为主．　　　兼容 MSSQL,DB2,infomix  .  你要参考下．　　引擎ＢＤＥ

Answer 9

人家叫你哈瑞,我也叫你这个吧. 哈哈 -------------------------------------没问题，偶想用的名称就是Harry，不过这个名字一般注册不到，所以才加了Fin做后缀，具体含义省略字数数千我们的曾经的一个产品(比较大)．呵呵．至少数据是集群的．　 业务逻辑以 Procedure 为主．　　　兼容 MSSQL,DB2,infomix  .  你要参考下．-----------------------------------------------------求学习... 其实我是中间派，倾向按需决定。不过如果主用存储过程的话，我觉得存储过程的粒度会比较重要，同时也最好引入分层的概念（逻辑上的分层）。

Answer 10

建议华仔另开帖讲课
如何做到兼容不同类型数据库，尽量采用标准SQL语法？