看我做的数据库包装器

flashair1983

哎。。。看了两位的帖子，我觉得我现在能拿这么一点工资足够了，跟你们相比感觉自己还什么都不懂，不再抱怨工资低了，好好看书，学习！！   努力！  奋斗！！

qingyun

原帖由 yulihua49 于 2009-2-27 15:44 发表

学习了。我原来以为使用SQLDA结构接收变量的是动态语句（好像ORACLE的文档里这么说的，记不清了）。
那OCI全是动态了？PRO*C呢？
那newkid坚决反对就没法照办了，PRO*C和OCI总不能不用吧？JDBC呢？漫天漫地的啊，Hibernate都不太支持存储过程的啊都是用语句的。
好在我还是bind了，语句的解释只一次。像TUXEDO，启动后，第一次服务，语句就解释了，它是驻留的进程，以后的服务效率会很高的。

就算bind了，也是动态语句，只不过执行计划能够有更多的几率被复用，动态语句的性能缺点体现很很多方面(细节我就不清楚了)
我的说法，未必正确，呵呵，权威的东西，要看newkid 兄的；

newkid

我测试结果是差3倍，与newkid的结果一样。所以我在前边的帖子里一再说，DAU为你保留游标，提高了性能。
而且保留了bind树，不论显示隐式，连bind都省了，很少谁的程序能做出这个。
再一次提示朋友们，包装器，不会比系统性能更好，但是很可能比你自己写的程序性能好。

我们两个提速的原因不一样。你是因为用了绑定变量和CACHE游标，这两个特性PLSQL本来就有的。
而我原来的程序是多取了不需要的数据。10G的FOR游标作了优化，默认成批取100条（如果你这游标小于100条则是全部取出），它这个“优化”的前提是你取出来的数据都是要访问的，不会提早退出循环，那么成批取当然比单条取要快。而我这个过程往往是提早退出的，成批取反而弄巧成拙了。

那OCI全是动态了？PRO*C呢？
那newkid坚决反对就没法照办了，PRO*C和OCI总不能不用吧？JDBC呢？漫天漫地的啊，Hibernate都不太支持存储过程的啊都是用语句的。

可以这么说，对ORACLE是动态的。如果在编译代码的时候SQL不可知，就是动态的。即使你写了个语法错的SQL，编译时也不知道。
但如果加上你的包装器，不但编译时不知道，连SQL都看不见了，因为它要运行时才自动生成。这可谓动态的动态，假如你的数据库访问出现了瓶颈，看源代码是看不出哪里不对劲的，得去找它生成的SQL, 再回过头来找生成这SQL的代码，很不直观，所以我说是制造障碍。
放到存储过程里则是静态的。

TUXEDO在低负载时具有超线性，大负载时具有线性特征，而J2EE具有非线性特征，而且过载极易崩溃。
TUXEDO是服务器池方式，大量呼叫涌入，没有空闲服务可用时，呼叫请求被排队。其调度策略很好，大规模压力测试表明负载完全是线性的，不会崩溃。

J2EE为什么非线性？因为JAVA的多线程，又大量存储分配，在公共的池里分配，必然互斥。还有垃圾收集，是不可控的过程。在大负荷下是否有内存可用是不确定因素。

J2EE用连接池，和你的“呼叫请求被排队”是同样的原理。如果把工作放到存储过程，减少JAVA端的负载，我相信是可以做到线性的。
你不是有JDBC比SDBC对比测试的环境吗？有没有试过调用存储过程的负载情况？

你说的TUXEDO用调度器分配资源的方式，和ORACLE的SHARED SERVER(即MTS)非常像，只不过现在大家都用连接池，SHARED SERVER很少用了。

我现在用的还是三年前的老电脑，如果我们各拿自己的测试结果出来比较那就是关公战秦琼，最好的比较方法是全放到你的环境里，你改一个调用存储过程的版本，然后用你的方法来测试。

这个“席位发布”程序等我有空看看，如果需要表数据结构我再向你要。

newkid

大致看了一下，不出所料的是逐行插入的。我如果来写一个存储过程（把你命令行的日期、车次作为入参。mkxw和xwfb的参数 carno 没有用到？），里面只有一个或几个INSERT...SELECT...,同样来生成上百万张票，你猜谁更快？

你觉得自己这个程序可读性如何？（我相信除了我没有第二个人吃饱了撑的把它看完）

再来看生产率。你写这个代码花多少时间？如果你把你的需求讲清楚，我写一个SQL只要花几分钟你信不信？

我需要你这些表的结构说明，和测试数据(你可以给我DMP)：
PRE_SEAT/PRE_SEAT_INDEX: 母表?
STOP_STATION/cz: 停靠站表?
seat: 生成的席位?
SEAT_REMANT:不明？

业务规则也需要给我讲清楚，光看代码我不能确定。

stu是为dau存绑定变量的？

[ 本帖最后由 newkid 于 2009-2-28 03:00 编辑 ]

yulihua49

原帖由 newkid 于 2009-2-28 02:57 发表
大致看了一下，不出所料的是逐行插入的。我如果来写一个存储过程（把你命令行的日期、车次作为入参。mkxw和xwfb的参数 carno 没有用到？），里面只有一个或几个INSERT...SELECT...,同样来生成上百万张票，你猜谁更快？

你觉得自己这个程序可读性如何？（我相信除了我没有第二个人吃饱了撑的把它看完）

再来看生产率。你写这个代码花多少时间？如果你把你的需求讲清楚，我写一个SQL只要花几分钟你信不信？

我需要你这些表的结构说明，和测试数据(你可以给我DMP)：
PRE_SEAT/PRE_SEAT_INDEX: 母表?
STOP_STATION/cz: 停靠站表?
seat: 生成的席位?
SEAT_REMANT:不明？

业务规则也需要给我讲清楚，光看代码我不能确定。

stu是为dau存绑定变量的？

SEAT_REMANT：余额表。其余理解正确。cz就是stop_station，上车站。和下车站都在stop_station里。
现在在家，下周出差，到时给你。stu指struct，公司新近要求用_stu后缀指明模板结构定义。
DAU整合的资源中，stu是数据记录存储区，通常是一个结构（struct）。
你几分钟写一个存储过程我信。但要解决这个问题有点难。我们前边讨论的问题，我都没跟你计较细节，仅仅测试性能。
这个例子我本没打算真玩。
有几个问题你要注意：
一个车次可能有好几组席位分配方案，周期使用。在车次表里，beg_date既表示该车次的有效起始日期，又表示周期的起始点。
cycle字段表达一个周期，如 1020，表示第一天开1组，第二天不开，第三天开2组，第4天不开。以后周而复始。
strlen(cycle)表示周期长度。席位发布时，算出哪组发哪组，0不发。
xwfb的下列代码是计算周期：
                i=(jobday-train->beg_date)%strlen(train->cycle);
                i_item=train->cycle〔i〕;
            
                if(i_item=='0') continue;

i_item是组号。结构成员名就是列名。jobday是作业日期。如果2月1日发布，就要发布2月11日的车，jobday就是2月11日。但有的车次特殊，就在train.days里指明，比如30，于是，jobday＝today＋train.days;
卧铺要注意一下，一般母表里指定beg_seatno，end_seatno,一个席位组，一席一号。硬卧是一席3号，下中上。软卧是一席一号单下双上。seat_type:20=硬卧，21硬卧下，22硬卧中，23硬卧上，30软卧，31软卧下，32软卧上。母表是抽象的20，30，席位是具体的。

业务本来就是有点复杂，你要是用PL/SQL写出来，要比我难懂10倍。
刚发现帖子里把〔i〕都弄成斜体了，数组下标不见了，程序没法看。

[ 本帖最后由 yulihua49 于 2009-2-28 21:43 编辑 ]

newkid

哈哈，我不相信难得住我。就等你数据结构了！最好给我你生成的结果，我可以对比。

还有，把你这段代码生成的SQL每种发一个给我。其实我只要WHERE部分。

你贴程序时，可以选择那个“插入代码标签”，就是“<>”按钮，就不会被转义了。

[ 本帖最后由 newkid 于 2009-3-1 09:05 编辑 ]

收章马甲

果真高手，佩服。

newkid

在你#272贴的帮助下把程序看懂了。现在我只需要你的数据结构作最后的确认。
你这个程序只能发布一天的吗？最好能把需求改为发布一个日期区间的。数据量越大越能体现SQL的优势。
实际应用中重复发布的情况多不多？如果不多的话我就只考虑INSERT就够了，用不上MERGE。

wildcatqfj

原帖由 ShingU 于 2008-12-4 15:41 发表
然而，我发现太多的人都把数据库当成是一个黑盒（black box），好像不需要对它有深入了解。他们可能有一个SQL生成器，认为有了这个工具，就不需要再费工夫去学SQL语言。也可能认为使用数据库就像使用平面文件一样，只需要根据索引读数据就行。不管他们怎么想，有一点可以告诉你，如果按这种思路来考虑，往往会被误导：不了解数据库，你将寸步难行。

顶  本人最反感的是hibernate之类的东西

nyfor

据 Oracle 文档介绍, Pro*C 使用的并非是 OCI (也许最终使用的是 OCI 吧), 它使用的是依赖于 Oracle 版本的 SQLLIB 库, 当然 Pro*C 中也可以直接调用 OCI.  

非常佩服本帖中两位的针锋讨论.

楼主在这个版块发这样的帖子, 引来的必定是一片的质疑声(包括我).

我觉得楼主不应该强调你的包装器的性能, 或许你应该强调的是使用你的包装器带来的开发效率(当然对于不太了解Oracle,不太了解SQL的程序员来说).

通看整片帖子的过程中, 我曾想起过以下词句(只当做调侃,别无它意): 龙芯一号, 汉语编程, 方舟子.

诚然, 对于楼主的包装器它固然也有它的优点(那些优点对于精于Oracle数据库编程的人员来说可能完全是缺点).

把这贴再顶起来, 另外建议 newkid 以本为内容发布一新帖, 不给你加一个精华, 实在是.....