看我做的数据库包装器

newkid

我不太清楚你们用的TUX那一套东西，要是我来做凡是能在数据库里完成的，包括口令、权限校验等，一律在数据库里完成。还是原来那句话：数据没有离开数据库，没有通过网络进入到C服务器再运算再送回来，这就是效率的保证！

我说的跟踪调试和你说的不太一样，我是说当看到表里有错误数据时，知道是从哪里来的，因为事务在数据库里。
你说的是DML失败（数据被回滚），这是错误日志的任务。用存储过程当然也有错误日志。

你们不用存储的理由简直是荒谬！SYBASE的页面锁是无法和ORACLE的行锁比拟的; PL/SQL的功能T-SQL是望尘莫及; ORACLE的多版本控制特性、写操作不阻塞读操作更是独步天下。你们竟然把SYBASE的短处算到ORACLE头上，可说是无知! 用你的方法，不过就是把存储过程里的SQL抽离出来到写在C服务器中, 最终还是一条一条扔回数据库执行，能比存储过程更好才是奇怪了!

我这里摆个擂台：
给出你们的需求，我来写存储过程，你用你的方法，不论你用什么测试工具，看看哪个效率高！

yulihua49

原帖由 newkid 于 2008-12-3 10:12 发表
我不太清楚你们用的TUX那一套东西，要是我来做凡是能在数据库里完成的，包括口令、权限校验等，一律在数据库里完成。还是原来那句话：数据没有离开数据库，没有通过网络进入到C服务器再运算再送回来，这就是效率的保证！

我说的跟踪调试和你说的不太一样，我是说当看到表里有错误数据时，知道是从哪里来的，因为事务在数据库里。
你说的是DML失败（数据被回滚），这是错误日志的任务。用存储过程当然也有错误日志。

你们不用存储的理由简直是荒谬！SYBASE的页面锁是无法和ORACLE的行锁比拟的; PL/SQL的功能T-SQL是望尘莫及; ORACLE的多版本控制特性、写操作不阻塞读操作更是独步天下。你们竟然把SYBASE的短处算到ORACLE头上，可说是无知! 用你的方法，不过就是把存储过程里的SQL抽离出来到写在C服务器中, 最终还是一条一条扔回数据库执行，能比存储过程更好才是奇怪了!

我这里摆个擂台：
给出你们的需求，我来写存储过程，你用你的方法，不论你用什么测试工具，看看哪个效率高！

技术路线上边决策，我又管不了。

我也想测一下，有难度。
数据结构倒是可以给，数据量太大，dmp的给？
程序也是满长的。
摆几十台终端我也弄不起。不过部分功能可以试试。

[ 本帖最后由 yulihua49 于 2008-12-3 11:55 编辑 ]

newkid

"技术路线上边决策，我又管不了。"
我原来一直以为只是你们公司的技术偏好，毕竟一个事务的逻辑采用C或PLSQL实现差不到哪里去，大家当然都喜欢选用自己顺手的开发语言。我还试图从不采用存储过程的角度提建议，比如在WHERE中应用绑定变量，尽量使用SQL本身已有的功能，放弃动态模板采用静态模板生成的程序等。
但#54的贴子让我大跌眼镜，原来偏见如此之深！竟然认为存储过程是“堵车”的罪魁祸首，还是“无药可救”的“死症”，这我就忍无可忍了！


"我也想测一下，有难度。"
你们以前不是作过类似测试吗？就用相同的环境，只是把业务处理放到存储过程，改一下调用方法。


"数据结构倒是可以给，数据量太大，dmp的给？"
这是你们的商业机密，当然不能给了。只要你说明取值范围和数据量，我可以用SQL来生成仿真数据。包括数据结构你也可以作修改，不一定要和原来的一样。


"程序也是满长的。"
就把你认为存储过程会造成“堵车”的几个部分拿出来测好了。


"摆几十台终端我也弄不起。不过部分功能可以试试。"
就用一个终端，写程序发出模拟并发的请求，这难不住你吧？
数据库部分很容易隔离测试。单用户情况就用PLSQL循环调用，记录每个事务所用时间。多用户情况可提交几十个JOB, 每个JOB模拟一个终端，里面有若干个事务。模拟的事务也要尽可能仿真，这需要你提供行业经验。
数据库的集成测试也不难，就是提供接口给你的程序调用，但我要求有连接池，不能每个事务建立一次连接。


作为热身运动，我建议你把SYBASE里面造成堵车的存储过程以及数据结构贴出来，我来示范一下用ORACLE该如何实现。
当然方法是完全不同的，我绝不会“以临时表为单元，大量的临时表创建、删除”。

newkid

原帖由 zhangfengh 于 2008-12-3 14:47 发表




真刀真枪的pk了

我从来就不是光说不练的

ShingU

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

dingjun123

楼主公司要的是快速开发，性能还可以就行了，而且最重要的是可以跨数据库，做产品的大多如此，没有什么可争的！

不过楼主说他的性能最好，那是不可能的，你弄了那么多层，难道有直接从数据库中来的快？大型应用一般不会迁移oracle到其他的什么sql，sybase之类的，如果要实现很简单的切换数据库，要做的工作实在太多，而且永远不可能比直接针对某个数据库写sql，pl/sql强！

单线程比多线程快？搞不好并发？？多进程很快？多进程占用资源多还是多线程占用资源多啊？不过你觉得适合就行了，我们公司也有类似的东西，都是用来快速开发的，满足要求就行，以后出性能问题了，再改，具体来说，肯定不如直接写sql，pl/sql来的好

sunfly1983

做的就像hebernate之类的东西？

newkid

谈到快速开发，我只用一个ULTRAEDIT文本编辑器，生产力照样很高，一个人对付十几个JAVA程序员绰绰有余。

dingjun123

原帖由 newkid 于 2008-12-4 23:00 发表
谈到快速开发，我只用一个ULTRAEDIT文本编辑器，生产力照样很高，一个人对付十几个JAVA程序员绰绰有余。

佩服，跟你混了，哈哈！

yulihua49

原帖由 sunfly1983 于 2008-12-4 22:39 发表
做的就像hebernate之类的东西？

原先有些东西，用了十几年了。后来被逼用hebernate思路，可是C又不是对象，就弄成这个东西，被公司认可。
效率可以这么看，hebernate是靠反射找到对象里的变量，C是靠映像图找到结构里的变量。反射程序我做过，开销要比直接映像大若干数量级，人家hebernate还不是用的好好的？C干这活本来就比JAVA快很多。直接映像，说白了，就是地址计算＋sprintf＋sacnf。，模板的地址计算只进行一次，以后，不管使用多少次，都是首地址＋偏移量，一条加法指令而已，有什么开销呢？前边的next（）程序你们也看了，这是最频繁的程序，说是一层包装，又有什么开销呢？包装的大部分开销都在init、open、new、connect等等初始化程序里，那只用一次的啊。实际上这个程序并未发现比OCI增加了什么开销，它的速度就是OCI的速度。每秒60000个fetch，每个fetch 17微秒。

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