看我做的数据库包装器

xzh2000

很好啊,技术上的讨论,清者自清...

Toms_zhang

技术这个东西,不同的人有不同的看法，这个也是正常的.

yulihua49 写出这个工具,也是下了不少功夫,也有一定的适用意义,也不能给人家一下否定了,但别人的提的意见呢,yulihua49 也要虚心的接受,Oracle已经实现了的经过考验的这些功能和特性,自己再浪费时间去从头做起,我觉得也是浪费时间.

比如yulihua49的这个观点:"关于效率，如果业务逻辑复杂，C程序效率更高，我不相信PL/SQL处理复杂数据能比C快。除了ASM，谁也没可能比C快"
就是你对Oracle的认识还不够,这方面的知识你可以去了解一下Oracle 的"PL/SQL纯编译"相关知识.

newkid

你是来个全盘否定，连个二分法也不用。
我不想反驳你，但也不能被你说服。
不管怎么说，我们的程序是离不开DAU的。
它所创造的劳动生产率是你无法比拟的。就像一个雕塑师傅无法与铸造厂比生产率一样。师傅可以有一万条理由说铸造的工件不如艺术品。

你我在各自领域里都可算是久经沙场了，岂是轻易能被说服的？我是旗帜分明，你也可以针锋相对嘛，前面我列了几个技术问题你都没有回答。我是不喜欢用太多文学修辞的，那样扯下去就没完了。

你何时见我用select *了？我是坚决反对如此用法。只有你的例子是。你那个insert，不写列名，等同于select *。

你没有理解我的意思。select * 在硬解析的时候是会被转成列名的，我反对的是你把所有的列都取出来，不管有没有用到（相当于SELECT *），并不是你在代码里写了SELECT *.

特别是当结果有聚合运算时，……可以手工建立分组模板。非常简单的，可以直接调用sdbc或sqlora，这两个东西是需要自己写语句的，我们的程序有这样的调用，我早说过，不是100%的。

我举这个例子是为了说明试图把计算移出数据库是不可取的。既然你也用SQL作聚合运算，那么参见另一个表连接的例子。把表连接移出数据库是很不明智的作法。Databases were born to join! (TOM语录)
其他例子如子查询、分析函数、CONNECT BY遍历树或图，随便哪个，如果你试图用C来实现，都将是吃力不讨好！

框架系统用到这个份上，存储过程不能支持模板，在我看来是最重大的缺陷。模板是一次定义多次使用的，实在是一个合算的买卖。

模板意味着动态SQL, 这个我是坚决反对的。它隐藏了数据库编程最有用的信息，SQL不可知，查询计划不可知，给调优、排错制造了障碍。
模板是服务于你那种编程思路的（把一切数据当作二维数组，并有一个套路处理结果集，如TOJASON），在PLSQL的世界里，模板完全失去意义，只有副作用。

关于效率，如果业务逻辑复杂，C程序效率更高，我不相信PL/SQL处理复杂数据能比C快。除了ASM，谁也没可能比C快。
我还是这个观点，数据库管理好数据，保证完整、正确、快速存取。其他事让别人做。

前面我做了个售票过程，后来你说业务要保密；那我就开始点菜了啊：那个自动生成空票的业务模块，我们来比试一下如何？你可以把原始需求保密，修改到你认为对包装器最有利的状态。
在这个论坛上每天都有杂七杂八的SQL问题，我也大量参与其中，如果你看中了哪个问题，认为用你的包装器做比较好，我们也可以来玩玩。

newkid

原帖由 cuicg 于 2009-2-24 10:50 发表
如果你们两个是同事，我猜十有八九会打起来，哈哈

那我早就很有风度地逃之夭夭了，据说他的老板是讨厌存储过程的！
yu老师是个令人尊敬的对手，看得出是个痴迷于技术，脱离了低级趣味的人！

cuicg

两年前我特别讨厌存储过程，准确的是害怕，还阻止别人使用存储过程，已开发调试不方便为理由！

现在只要是复杂一点的业务逻辑，我就往存储过程上靠，嘻嘻

看来我也着魔了！

qingyun

楼主的包容器，就算再好，我觉得有3大硬伤：
1.用C开发，很多人不是很懂，大部分人都是搞java的；特别是数据库方面，鲜有听说用C的；所以你这个包容器如何让别人和你协助开发是个问题；
2.现在不是有现成的ejb，hibernate等数据访问层框架，有必要你再搞了类似功能的C的包容器，就算你做的比他们好，你又怎能以一己之力抗衡之；
3.对于Oracle，它本身就是java开发，所以它和java更有天然的交互性；

我觉得楼主可以把你的包容器做成一个开源框架，让相关的爱好者共同参与完善；可能会成为一个气候。也是不错的选择；

newkid

原帖由 qingyun 于 2009-2-25 11:37 发表
楼主的包容器，就算再好，我觉得有3大硬伤：
1.用C开发，很多人不是很懂，大部分人都是搞java的；特别是数据库方面，鲜有听说用C的；所以你这个包容器如何让别人和你协助开发是个问题；
2.现在不是有现成的ejb，hibernate等数据访问层框架，有必要你再搞了类似功能的C的包容器，就算你做的比他们好，你又怎能以一己之力抗衡之；
3.对于Oracle，它本身就是java开发，所以它和java更有天然的交互性；

我觉得楼主可以把你的包容器做成一个开源框架，让相关的爱好者共同参与完善；可能会成为一个气候。也是不错的选择；

楼主坚持用C是因为其性能。其实，如果用JAVA+存储过程，一点也不会比C差的。
这个包装器目前的小众化状态也是一个问题。如果我是楼主公司的程序员，把时间用在掌握这个包装器编程对我的成长是不利的，学不到数据库的精髓（SQL），又学不到流行的架构，以后想跳槽咋办呢？那么我更愿意去学一些大路货的技术。从这个意义上说，楼主做的是一个孤芳自赏的艺术品。
我前面问的连接池的问题楼主没有回答，至今也不知道数据库连接是否共享的，如果是像以前的C/S那样的持久连接，局限性就更大了。
ORACLE本身是用C实现的，当年它推出数据库的时候JAVA还是气体呢。它有很多副产品是用JAVA做的。

qingyun

原帖由 newkid 于 2009-2-26 01:57 发表


楼主坚持用C是因为其性能。其实，如果用JAVA+存储过程，一点也不会比C差的。
这个包装器目前的小众化状态也是一个问题。如果我是楼主公司的程序员，把时间用在掌握这个包装器编程对我的成长是不利的，学不到数据库的精髓（SQL），又学不到流行的架构，以后想跳槽咋办呢？那么我更愿意去学一些大路货的技术。从这个意义上说，楼主做的是一个孤芳自赏的艺术品。
我前面问的连接池的问题楼主没有回答，至今也不知道数据库连接是否共享的，如果是像以前的C/S那样的持久连接，局限性就更大了。
ORACLE本身是用C实现的，当年它推出数据库的时候JAVA还是气体呢。它有很多副产品是用JAVA做的。

newkid兄说道了C/S那样的持久连接问题，我也一直为这个头疼，我是开发自动仓库信息系统的；
仍是用c/s开发；用的技术（delphi+odac(一个第3方的oralce专用数据引擎,类似ado)+oralce10g)

为了防止持久连接问题：
我以前这样处理，应用软件每执行一个sql操作，就关闭session，再用的时候再打开session；也就是session很少；只是用的那一瞬间才有用；但是这有个很大的问题，就是本来建立session对于oracle来说就是一个很“重”的操作；不建议频繁开闭；也许mssql频繁开闭无所谓；oralce的session建立远大于mssql做的事情；它们机制不一样；可以使用共享服务器模式，但是如果连接不多的话，据说还是专用模式好。
  所以后来，我放弃这个做法了，感觉得不偿失；还是就让它持久连接吧；再说客户端也不是那么多，也就几十个而已；而且任何时刻你去查询select status from v$session ，基本都是INACTIVE状态；我想这样状态的session应该也占不了什么资源吧(这个说法对否？)；
  我也听说用连接池技术，比如我们就设置池的大小为20个；那么就算客户端同时开着200个也无所谓；因为同时actice的seeson毕竟很少；对于那个inactive的session可以随时在各个客户端里“借来借去”；
但是这个技术不会用，感觉要专门做个proxy代理才行；连接池技术是应用程序的调度问题，好像和oracle本身没有关系，任何数据库都有session；j2ee可能对连接池控制的比较好；
  不知道连接池技术和oracle本身没有直接关系，而是应用程序自身调度控制的 这个说法对否？

后来怎么办，我尝试做了job ，查看v$session里的不活跃的时间，查过一定时间，就打算kill掉；但这个不太好；这样会导致应用程序执行的时候因为没有数据连接而报错，
所以应该让应用程序自己决定；我通过utl_tcp传递信息给应用程序，应用程序收到后，自己关闭session；
但是也很麻烦，要应用程序建立一个socket通讯的tcp服务端；所以这个方法也放弃了；

最终就什么都不管啦。当然毕竟客户端少，Oracle默认的session也有170，就算不够也可以通过修改spfile搞大些；

我就不明白，如果大部分session都是不活跃的，多点应该也无所谓吧。

[ 本帖最后由 qingyun 于 2009-2-26 10:05 编辑 ]

yulihua49

原帖由 qingyun 于 2009-2-26 10:04 发表


newkid兄说道了C/S那样的持久连接问题，我也一直为这个头疼，我是开发自动仓库信息系统的；
仍是用c/s开发；用的技术（delphi+odac(一个第3方的oralce专用数据引擎,类似ado)+oralce10g)

为了防止持久连接问题：
我以前这样处理，应用软件每执行一个sql操作，就关闭session，再用的时候再打开session；也就是session很少；只是用的那一瞬间才有用；但是这有个很大的问题，就是本来建立session对于oracle来说就是一个很“重”的操作；不建议频繁开闭；也许mssql频繁开闭无所谓；oralce的session建立远大于mssql做的事情；它们机制不一样；可以使用共享服务器模式，但是如果连接不多的话，据说还是专用模式好。
  所以后来，我放弃这个做法了，感觉得不偿失；还是就让它持久连接吧；再说客户端也不是那么多，也就几十个而已；而且任何时刻你去查询select status from v$session ，基本都是INACTIVE状态；我想这样状态的session应该也占不了什么资源吧(这个说法对否？)；
  我也听说用连接池技术，比如我们就设置池的大小为20个；那么就算客户端同时开着200个也无所谓；因为同时actice的seeson毕竟很少；对于那个inactive的session可以随时在各个客户端里“借来借去”；
但是这个技术不会用，感觉要专门做个proxy代理才行；连接池技术是应用程序的调度问题，好像和oracle本身没有关系，任何数据库都有session；j2ee可能对连接池控制的比较好；
  不知道连接池技术和oracle本身没有直接关系，而是应用程序自身调度控制的 这个说法对否？

后来怎么办，我尝试做了job ，查看v$session里的不活跃的时间，查过一定时间，就打算kill掉；但这个不太好；这样会导致应用程序执行的时候因为没有数据连接而报错，
所以应该让应用程序自己决定；我通过utl_tcp传递信息给应用程序，应用程序收到后，自己关闭session；
但是也很麻烦，要应用程序建立一个socket通讯的tcp服务端；所以这个方法也放弃了；

最终就什么都不管啦。当然毕竟客户端少，Oracle默认的session也有170，就算不够也可以通过修改spfile搞大些；

我就不明白，如果大部分session都是不活跃的，多点应该也无所谓吧。

TUXEDO提供了服务器池。它预先启动一定数目的服务器进程。这些进程持久连接数据库。
客户端对TUXEDO的进行长连接。但这个连接只针对调度器，而不与任何一个服务器连接。
客户端一旦发出一个服务请求，调度器把服务转接到一个服务进程。服务完毕，连接回到调度器。
服务进程被占用时间很短暂，所以几个进程就可以支持大量客户端，而对数据库，仅仅是几个长连接。
每个服务请求无需打开和关闭数据库，所以速度很快。
服务器进程与客户端的比例，TUXEDO推荐1：500，我们计划1：100
我的实验，1000个用户以内的话，直接长连接就可以。TUXEDO都是为了对付数十万客户端的。

[ 本帖最后由 yulihua49 于 2009-2-26 17:02 编辑 ]

yulihua49

原帖由 newkid 于 2009-2-24 23:56 发表


那我早就很有风度地逃之夭夭了，据说他的老板是讨厌存储过程的！
yu老师是个令人尊敬的对手，看得出是个痴迷于技术，脱离了低级趣味的人！

谢谢。技术上的交锋可以增进友谊。