看我做的数据库包装器

yulihua49_cu

原帖由 newkid 于 2009-7-5 22:03 发表


你哪里看到我反对游标缓存了？我的意思：
1. 游标缓存比反复关闭、打开更好；但是! 能用一个游标（一个SQL）解决，就比多个游标（多个SQL）更快，哪怕你这多个游标是缓存过的!
2. 游标缓存在PL/SQL中一点都不稀罕，而且对程序员是透明的，你即使关闭了游标也会被缓存。

关于支持多数据库的通用系统，我前面也表过态了：
1.以你的售票模块为例，你换个数据库就得再写一遍。到头来和用存储过程的代价是差不多的。所谓的通用并不存在。
2.你前面的代码竟然以ROWID作主键，这是个低级错误，但愿你改过来了。
3.假设真的做出了通用的系统，那么必定以牺牲性能为代价，你用不到数据库的高级特性。
4.在现实中，数据库是作为应用的一个部件来推的。你推你的售票系统，同时必定推了TUXEDO, 推了ORACLE; 如果客户坚持要把ORACLE换掉，他同样有理由要求你改用JAVA.

一头雾水。我哪里说你反对游标缓存了？我只说，游标不关闭能提高效率。

我再写几遍也是平台，与应用没关系的。我写几个平台的DAU也不是完全为了这个应用，做什么都行，反正是平台。
我们谁也没推倒任何平台，只不过某些部分可能必须要使用XXX，但是不论这部分的数据来自XXX或ORACLE，应用代码无需改变。

就像ORACLE，要做UNIX的，AIX的，Z/OS的等等。
DAU就没牺牲什么性能，不比你慢啊！

对了，还是那个怪异问题。存储过程确实没有此问题。此问题为OCI所独有，肯定是OCI代码里有什么问题。

OCIlib接口同样存在。

[ 本帖最后由 yulihua49_cu 于 2009-7-6 16:26 编辑 ]

〇〇

本文来源于 WEB开发网 原文链接：http://www.cncms.com.cn/sybase/6540.htm
◇ 规模庞大： 如前所述，中国铁路有 5000 多个车站承办客运业务，日开行旅客列车 2000 多列，系统建成后将有几万个窗口机需要联网，每年客运量大于 10 亿人次，最高日发售客票高达 400 万张之多，...。

　　◇ 实时性强： ...，在售票高峰时，将会同时产生 4000 - 5000 个座席申请，其中有相当数量是对同一时间、同一车次、相同座席的请求。为保证响应速度，对网络时延的要求非常高，计算机处理一张票的总时间一般应小于 7 秒，其中网络通信时延要在 2 秒以内，...。

全路需建立一个全路中心数据库和 25 个地区中心数据库。

　　中国铁路客票发售与预订系统由中央级、地区级和车站级三层结构组成，包括全国票务中心管理系统、地区票务中心管理系统和车站电子售票系统。系统采取集中与分布相结合的方案，在全路票务中心内安装中央数据库，Sybase...Adaptive Server Enterprise、Replication Server、Adaptive IQ，中间件产品Open Client、Open Server以及开发工具PowerBuilder和PowerDesigner...；这一系统主要用于计划与调度全系统的数据，并接收下一系统的统计数据和财务结算数据。在地区票务中心设有地区数据库，Sybase的Adaptive Server Enterprise、Replication Server、Open Client、Open Server、PowerBuilder、PowerDesigner将全面支持这一数据库，它主要用于计划与调度本地区数据，并可响应异地购票请求。系统的基础部分是由Sybase的Adaptive Server Enterprise、Replication Server、Open Client、Open Server、PowerBuilder、PowerDesigner构成的车站售票系统，它主要具有售票、预订、退票、异地售票、统计等多种功能。中国铁路客票发售和预订系统实现了计算机联网售票，并且有出售返程、联程等异地购票的功能，实现了票额、座席、制票、计算、结算和统计等计算机管理，...。


本文来源于 WEB开发网 原文链接：http://www.cncms.com.cn/sybase/6540.htm

yulihua49_cu

原帖由 〇〇 于 2009-7-6 09:42 发表

    绑定变量主要适用在Oltp，运行时间很短的系统。如客服系统，时时地进行insert方面的系统。 数据仓库系统不适用，和数据库仓库系统的一条sql运行时间相比，硬分析的代价显然是微不足道的，通过硬分析去选择正确的执行计划才是关键。

  简单一句话，在Oltp系统中应用绑定变量，性能会有质的提高。



                                                                                                                ---引（http://www.apub.org/doc/2006/03/11/10/52/26/21883.html）

极其赞同。
所以DAU也是偏向OLTP的。所以前边做OLAP的朋友，我并不太推荐DAU。但是我也可以测试一下DAU在OLAP中的性能，优点与缺点。

yulihua49_cu

原帖由 〇〇 于 2009-7-6 16:21 发表
本文来源于 WEB开发网 原文链接：http://www.cncms.com.cn/sybase/6540.htm
◇ 规模庞大： 如前所述，中国铁路有 5000 多个车站承办客运业务，日开行旅客列车 2000 多列，系统建成后将有几万个窗口机需要联网，每年客运量大于 10 亿人次，最高日发售客票高达 400 万张之多，...。

　　◇ 实时性强： ...，在售票高峰时，将会同时产生 4000 - 5000 个座席申请，其中有相当数量是对同一时间、同一车次、相同座席的请求。为保证响应速度，对网络时延的要求非常高，计算机处理一张票的总时间一般应小于 7 秒，其中网络通信时延要在 2 秒以内，...。

全路需建立一个全路中心数据库和 25 个地区中心数据库。

　　中国铁路客票发售与预订系统由中央级、地区级和车站级三层结构组成，包括全国票务中心管理系统、地区票务中心管理系统和车站电子售票系统。系统采取集中与分布相结合的方案，在全路票务中心内安装中央数据库，Sybase...Adaptive Server Enterprise、Replication Server、Adaptive IQ，中间件产品Open Client、Open Server以及开发工具PowerBuilder和PowerDesigner...；这一系统主要用于计划与调度全系统的数据，并接收下一系统的统计数据和财务结算数据。在地区票务中心设有地区数据库，Sybase的Adaptive Server Enterprise、Replication Server、Open Client、Open Server、PowerBuilder、PowerDesigner将全面支持这一数据库，它主要用于计划与调度本地区数据，并可响应异地购票请求。系统的基础部分是由Sybase的Adaptive Server Enterprise、Replication Server、Open Client、Open Server、PowerBuilder、PowerDesigner构成的车站售票系统，它主要具有售票、预订、退票、异地售票、统计等多种功能。中国铁路客票发售和预订系统实现了计算机联网售票，并且有出售返程、联程等异地购票的功能，实现了票额、座席、制票、计算、结算和统计等计算机管理，...。


本文来源于 WEB开发网 原文链接：http://www.cncms.com.cn/sybase/6540.htm

我们正是在对这个系统进行换代工作，它原来使用SYBASE，太轴了，根本不能适应全国统一的集中数据库系统。
要想升级为全国系统，其性能至少升级18倍。
那么我们：
1.换ORACLE，性能×4
2.使用RAC × 4
3.用TUXEDO分担负载 ×2  最主要用于防拥塞，现系统拥塞太严重了。
4.改进应用数据结构和算法 × n

这样我们的总性能×32n，现有设备无需升级即可满足要求。

不仅是速度问题，原系统OLTP与OLAP互相干扰太厉害了，进行大规模调票、统计、查询时卖不动票。
ORACLE环境，OLTP与OLAP互相干扰非常轻，ORACLE有比较好的技术减轻这种干扰。实测证实。

[ 本帖最后由 yulihua49_cu 于 2009-7-6 16:48 编辑 ]

chwp

好不容易看了一遍
都是高手！学习中。。。

希望不用看到每天车站前的人山人海，冬练三九夏练三伏！

newkid

原帖由 〇〇 于 2009-7-6 09:42 发表


结论：

    绑定变量主要适用在Oltp，运行时间很短的系统。如客服系统，时时地进行insert方面的系统。 数据仓库系统不适用，和数据库仓库系统的一条sql运行时间相比，硬分析的代价显然是微不足道的，通过硬分析去选择正确的执行计划才是关键。

道理是没错，但是数据仓库里也可用绑定变量。用绑定变量还有安全方面的考虑，可以防止SQL注入。至于执行计划，9i引入的BIND VARIABLE PEEKING已经解决了大部分问题。实在要用硬解析的话，因为必定要用到动态SQL, 那么玩点小花样每次生成不同SQL是轻而易举的（比如在SQL嵌入不同的注释），绑定变量的原则不变。

newkid

原帖由 yulihua49_cu 于 2009-7-6 16:09 发表

我再写几遍也是平台，与应用没关系的。我写几个平台的DAU也不是完全为了这个应用，做什么都行，反正是平台。

你这个平台是为了应用的业务逻辑服务的，在我看来在此平台上进行开发没有任何好处，远不如用PLSQL，因此你这层包装是完全没必要的。
代码摆在那里，你去问任何一个程序员看看哪个容易读、容易开发、容易维护（不要问你的徒弟，因为答案我已经知道了）。
ORACLE本身就是一个很好的虚拟机，在此基础上再作包装已经没有必要了。当然前提就是要用ORACLE。

你的DAU都是生成最简单的单表操作SQL, 当然不可能用于OLAP了。

yulihua49_cu

原帖由 newkid 于 2009-7-6 23:08 发表


你的DAU都是生成最简单的单表操作SQL, 当然不可能用于OLAP了。

否。
那个席位发布程序就是一个典型的OLAP，干的很好呀！
包装也未必慢，穿鲨鱼皮或海豚皮泳衣还是比裸泳快一点点的。
DAU对OLAP主要问题是有时必须手写一些模板，需要一些技巧的。
有时还会要求按照DAU的特点设计数据结构，以便获得更好的效率和方便编程。

[ 本帖最后由 yulihua49_cu 于 2009-7-8 11:02 编辑 ]

yulihua49_cu

原帖由 newkid 于 2009-7-6 23:08 发表

代码摆在那里，你去问任何一个程序员看看哪个容易读、容易开发、容易维护（不要问你的徒弟，因为答案我已经知道了）。

DAU才出生不久，人们根本就不了解，我也没有向其他任何人提供开发包和技术说明。
坛子里ORACLE高手云集，这么比赛不公平吧？

通过招收新毕业的软件专业大学生，要求他们粗通C语言和SQL概念。

我培训他们两个小时，做两个小时习题。（我在IBM实验室就这么做的，一帮孩子们把DAU的DAO程序从ORACLE改成TPF，干的很好），
你培训他们4个小时PL/SQL，

然后给他们任务，看他们用那个平台完成任务的速度快，程序质量好。

[ 本帖最后由 yulihua49_cu 于 2009-7-8 11:14 编辑 ]

newkid

原帖由 yulihua49_cu 于 2009-7-8 11:00 发表

否。
那个席位发布程序就是一个典型的OLAP，干的很好呀！

你觉得是OLAP? 你这理解可够独特！去这里看看，哪里能对上号？
http://en.wikipedia.org/wiki/OLAP

无非就是一个批量事务而已。

我不知道现在的大学教育发生了什么变化，当年我毕业时已经能够写复杂的C程序，但是对SQL几乎一无所知。因此你的比赛条件也是不公平的。