看我做的数据库包装器

newkid

呵呵，你认为SQLLOADER是“存储过程”？先搞清楚概念再说。

我前面鼓吹的“存储过程”，是针对你在“数据包装器”上写的事务处理单元，比如你那个售票模块，你的“存储过程造成堵车”理论激我写出了一个同样功能的存储过程，至今也没有见到你的对照测试结果，或堵车的证据。不过后来好像你的看法有些松动，也不知道对存储过程的偏见解除了没有。我的观点是用PLSQL写的存储过程优于用C在你的包装器上写的事务处理单元，不管你从哪方面比较。

后来你开始秀你的数据加载工具，仍然是在你的“包装器”上进行开发。尽管你曾发誓“永远不会使用绑定变量”，后来又改变了看法，这是可喜的进步，但在我看来还是完全没有必要。我不用“存储过程”和你比，我用的是ORACLE本身提供的各种数据加载手段，比如SQLLOADER, 外部表, 还演示了MERGE INTO进行稍微复杂的数据处理（你要是非得把这个MERGE INTO称作存储过程也未尝不可，但一般我们都是放在SQL脚本执行就行了）。这些都仅仅需要很少（或者根本没有）的代码量，而性能是你自制工具不能及的（可以说，越是大的数据量，越是复杂的处理规则，你的方法就差距越大）。既然你使尽浑身解数也才达到83%，何苦去研制这个加载工具？

fuxiaoyang13

高人啊 ！！！！！！！！！！

xiaoe_7

没有时间看完，明天继续。

两个牛人，两种观点

fengzj

mark

nvlixue

两位大侠，观点的碰撞.....真张了见识

sunfly2010

呵呵，学习newkid大虾的专研精神啊

yulihua49

原帖由 newkid 于 2008-12-30 00:07 发表
呵呵，你认为SQLLOADER是“存储过程”？先搞清楚概念再说。

我前面鼓吹的“存储过程”，是针对你在“数据包装器”上写的事务处理单元，比如你那个售票模块，你的“存储过程造成堵车”理论激我写出了一个同样功能的存储过程，至今也没有见到你的对照测试结果，或堵车的证据。不过后来好像你的看法有些松动，也不知道对存储过程的偏见解除了没有。我的观点是用PLSQL写的存储过程优于用C在你的包装器上写的事务处理单元，不管你从哪方面比较。

后来你开始秀你的数据加载工具，仍然是在你的“包装器”上进行开发。尽管你曾发誓“永远不会使用绑定变量”，后来又改变了看法，这是可喜的进步，但在我看来还是完全没有必要。我不用“存储过程”和你比，我用的是ORACLE本身提供的各种数据加载手段，比如SQLLOADER, 外部表, 还演示了MERGE INTO进行稍微复杂的数据处理（你要是非得把这个MERGE INTO称作存储过程也未尝不可，但一般我们都是放在SQL脚本执行就行了）。这些都仅仅需要很少（或者根本没有）的代码量，而性能是你自制工具不能及的（可以说，越是大的数据量，越是复杂的处理规则，你的方法就差距越大）。既然你使尽浑身解数也才达到83%，何苦去研制这个加载工具？

现在使用bind，性能提高了5倍，达到SQL*load的8成。你比SQL*loader快？
现在正在改造系统，使之支持bind方法，难度比较大。你那个擂台肯定要打的，等我全面改造完了，就改写程序，打擂。
不光跟你打擂，还要跟IBM的TPF打擂呢。

那个loadsth，只是我的功能和性能测试器。83%已经是很不错的成就了（我想知道存储过程能达到多少？），完全具有实用价值。
程序好懂否？好写否？是否具有优良的数据适应性，这才是关键。

[ 本帖最后由 yulihua49 于 2008-12-31 17:31 编辑 ]

newkid

"83%已经是很不错的成就了（我想知道存储过程能达到多少？）......"
唉，怎么还说存储过程呢？我干吗用存储过程加载数据?我用SQL LOADER和外部表。外部表根本不用加载！

祝你在新年谱写新的篇章！

wuhuaT

原帖由 newkid 于 2009-1-1 01:41 发表


祝你在新年谱写新的篇章！

伊斯力

还在讨论呀   新年快乐