看我做的数据库包装器

〇〇

niukid和 yulihua49 的争论在我看来是
开发思路和商务思路的交锋
程序员总是想编程序达到最快最好成绩
商人要培养一群只用他的软件的用户
但是oracle也是商人的...

wabjtam123

开发版的NEWKID就是管理版的BITI，佩服的五体投地！

yulihua49

原帖由 〇〇 于 2009-9-21 23:18 发表
niukid和 yulihua49 的争论在我看来是
开发思路和商务思路的交锋
程序员总是想编程序达到最快最好成绩
商人要培养一群只用他的软件的用户
但是oracle也是商人的...

呵呵，我可不是商人，我只想写程序简单些。

yulihua49

原帖由 newkid 于 2009-9-21 23:02 发表

我不反对你用你的DAU方法去把数据库和C数据结构作映射；我只是不赞成你把事务处理拿到C里面去完成，也不赞成把复杂SQL分解成许多单表、嵌套游标的操作。
在我看来应该大量适用存储过程，存储过程里写复杂SQL是轻而易举，这是PLSQL的天生优势。
存储过程的计算结果你完全可以再用你的方法拿到C里去使用。但是我认为剩下的就是简单的输出而已，没什么事务逻辑需要实现。如果按我的思路来做，我不知道你的包装器还能起多大作用。

从存储过程返回的结果集，仍然要使用模板映射到结构，由于语句不是模板形成的，这个模板你要仔细了。
在存储过程里，你就享受不到模板带来的诸多好处，如一致性数据访问，日期格式的统一管理，统一的伪列名管理等等。

这里的观点是，不能给瓶颈资源过大的负担。数据库服务器是整个系统的瓶颈资源。
因此，不建议大规模使用存储过程。大量的业务逻辑必须在中间的应用服务器书写。

简单的输出并不简单，有什么办法能够一句话把一个数据结构打成一个JSON包？有什么办法能够一句话把一个数据结构打成一个网络传输格式？你可以在网上搜搜，这样的问题比比皆是。DAU以数据结构为中心，整合了数据库，串行化数据，json格式处理。。。。。

[ 本帖最后由 yulihua49 于 2009-9-22 12:05 编辑 ]

tom0732

原帖由 newkid 于 2008-12-18 00:38 发表
“见如下参数：bindsize=10000000 readsize=10000000”
这个是为了减少COMMIT次数和读取TXT文件的次数，跟SQL没有关系。用的仍然是绑定变量和传统路径加载(SQL)。
你可以把这个参数设到最大值20971520，COMMIT次数更少了因而速度也更快。


"我估计它是直接调用底层进行块读写，连SQL都不用。"
那个直接路径加载参数是DIRECT=TRUE, 我没有打开，就是想让它作传统路径的INSERT.

"全部IO时间只有0.5秒，估计是717条记录写一次。仅仅是bind，不可能减少IO时间的。"
不知道时间是怎么衡量的，但IO的减少和上述两个SQL LOADER参数有关。

"我的程序，user时间只有0.74秒，我优化到家，也就这点时间。这里边有多少是分析SQL的呢？"
去像我举例那样先做一个alter session set sql_trace=true; 再用TKPROF去分析跟踪文件，里面有解析时间。


"当年，INFORMIX-SE提供了底层操作C-ISAM,我们一直在用，比SQL快25倍呢。ORACLE没提供这东西，只留着自己用。"
谁说ORACLE没有提供？INSERT有APPEND提示可用; 但索引的维护是绕不过去的。绕过SQL也就跳过了REDO日志，有一定风险。
还有很多加载技巧，比如用外部表;DATA PUMP; 先DISABLE约束/删除索引，事后再重建。这些都是在ETL中使用的，像售票系统这样的OLTP很少加载外部数据。

"还有，ORACLE如此怪异，见我前边的日志和程序，"
照理说UPDATE开销最大，INSERT最小。你确定你的试验是在单用户环境下吗？如果有其他负栽，硬解析是很受影响的，因为里面使用了很多全局的LATCH. 你不妨在自己的PC机上装一个ORACLE作试验。

按理来说delete产生日志最多占用回滚也最大吧,update相对delete什么地方耗用资源多呢?

yulihua49

原帖由 newkid 于 2009-3-7 04:28 发表

他为了查询一条数据必须这么做：
stop_station.sequence=pre_seat.beg_station;
stop_station.beg_date=jobday;
if(get_stop_station(&cz_DAU,stmt)) continue;

而在遥远的其他地方，还有给train_no赋值的代码！strcpy(stop_station.train_no,pre_index->train_no);
你看得出stop_station和cz_DAU是有联系的吗？看得出为了查询一个数据要这么多窍门吗？
明明白白的编程方法：get_stop_station就应该有train_no,sequence,beg_date作为输入参数。根据这些参数查询数据库数据。
。

在所有的C里，绑定变量都是这么操作的，无可厚非。你想想PROC*C，先赋值，再语句，语句里绑定变量。无一例外。

newkid

原帖由 yulihua49 于 2009-9-22 11:37 发表

从存储过程返回的结果集，仍然要使用模板映射到结构，由于语句不是模板形成的，这个模板你要仔细了。
在存储过程里，你就享受不到模板带来的诸多好处，如一致性数据访问，日期格式的统一管理，统一的伪列名管理等等。

这里的观点是，不能给瓶颈资源过大的负担。数据库服务器是整个系统的瓶颈资源。
因此，不建议大规模使用存储过程。大量的业务逻辑必须在中间的应用服务器书写。

简单的输出并不简单，有什么办法能够一句话把一个数据结构打成一个JSON包？有什么办法能够一句话把一个数据结构打成一个网络传输格式？你可以在网上搜搜，这样的问题比比皆是。DAU以数据结构为中心，整合了数据库，串行化数据，json格式处理。。。。。

不知道为什么一定要映射到结构。我们以前都是把结果集当作二维数组来访问。
在11G以前，PLSQL不能动态访问REF CURSOR的结构。11G以后可以用DBMS_SQL实现了，因此你说的JASON打包，日期统一格式化输出，也就是一句话的事，做一个通用的格式化模块就可以了。当然这些用C来做我完全赞成，因为只是格式化。你不用结构，只需要写一个通用的模块访问结果集并对数据格式化。
"数据库服务器是整个系统的瓶颈资源" 你的偏见才是整个系统的瓶颈。你以前说售票模块会“堵车”，我写了一个存储过程并证明了它能高效运行；你的生成票据的模块，我也用更简单高效的方法实现了。对于你类似的没有论据的论点，我只有一句话：拿出实例来！

newkid

原帖由 tom0732 于 2009-11-25 13:29 发表


按理来说delete产生日志最多占用回滚也最大吧,update相对delete什么地方耗用资源多呢?

UNDO是DELETE占用多，REDO是UPDATE占用多。

newkid

原帖由 yulihua49 于 2009-11-29 20:34 发表

在所有的C里，绑定变量都是这么操作的，无可厚非。你想想PROC*C，先赋值，再语句，语句里绑定变量。无一例外。

我只是不喜欢你把赋值割得支离破碎，我认为应该是一连串紧挨着的语句，你阅读的时候才知道为了获得数据总共需要哪些参数。

newkid

TOM是PRO*C大师同时也是PL/SQL大师，看看他怎么评价这两种语言：

which is fast pro* c or pl/sql and why

http://asktom.oracle.com/pls/ask ... ON_ID:1138433172691