看我做的数据库包装器

badcatgarfield

原帖由 fflush 于 2008-11-25 16:18 发表

转换数据库这个问题在客户那里是很少见到的，但是软件公司的通用产品要应对不同的客户，不同客户有不同的需求，A喜欢Oracle，而B喜欢DB2，难道我们的产品都要为不同的数据库重写一遍吗？所以说，一个通用的中间层是必然的选择。

“通用的中间层”也要看通用到什么程度，最近在研究DotNetNuke，它的架构设计很不错，推荐你看一下。

Presentation Layer
Business Logic Layer
Data Access Layer (Partially Abstract)
Implementation of Data Access Layer (SQL Server, Oracle, MySQL, ....)

我认为这样的架构在平台的通用性与开发的成本、代码的易维护性之间找到了一个最佳的平衡点，最复杂的表示层与业务逻辑层完全通用，不管你用什么数据库。

如果更换数据库平台，只需重写最底层，以及数据库对象（过程、函数...）就行了，我相信这样做的代价，要远远小于维护一个复杂的要命的中间层，同时完全不能发挥不同的数据库平台各自的优势。当然，这样做的前提是不能把过多的业务逻辑放入存储过程，存储过程主要用来处理数据。

要完全脱离底层数据库，创建完全通用的应用，这样的想法是不现实的，得不偿失。大到操作系统，还有HAL层，还要安装硬件驱动呢，怎么没见有哪个公司出一个随便在什么电脑上拿过来就运转如飞的OS？

[ 本帖最后由 badcatgarfield 于 2008-11-25 17:43 编辑 ]

yulihua49

原帖由 badcatgarfield 于 2008-11-25 17:36 发表


“通用的中间层”也要看通用到什么程度，最近在研究DotNetNuke，它的架构设计很不错，推荐你看一下。

Presentation Layer
Business Logic Layer
Data Access Layer (Partially Abstract)
Implementation of Data Access Layer (SQL Server, Oracle, MySQL, ....)

我认为这样的架构在平台的通用性与开发的成本、代码的易维护性之间找到了一个最佳的平衡点，最复杂的表示层与业务逻辑层完全通用，不管你用什么数据库。

如果更换数据库平台，只需重写最底层，以及数据库对象（过程、函数...）就行了，我相信这样做的代价，要远远小于维护一个复杂的要命的中间层，同时完全不能发挥不同的数据库平台各自的优势。当然，这样做的前提是不能把过多的业务逻辑放入存储过程，存储过程主要用来处理数据。

要完全脱离底层数据库，创建完全通用的应用，这样的想法是不现实的，得不偿失。大到操作系统，还有HAL层，还要安装硬件驱动呢，怎么没见有哪个公司出一个随便在什么电脑上拿过来就运转如飞的OS？

感谢。有空学一下。必须以LINUX/UNIX为平台，WS的不玩，可以学学。

newkid

"怎么组装结构？没用过，请教。
“通用程序”，你写通用程序，怎么面对不知道的结构？JAVA可以有反射机制解析未知对象，C和C++都不可能。就只能靠模板了。 "

我也不懂，但你既然能够动态建立模板，就说明你能构建未知的结构。剩下的无非就是想办法取得结构描述（模板），你的方法是从数据字典取，而动态结果集的结构描述也是有办法取得的，参见这个例子（OCI）：
http://www.webservertalk.com/archive149-2006-5-1530568.html

里面8楼有个例子。

"调优，主要是分析where子句，……"
你可能没有碰到复杂的查询，有时候会调整写法，用到嵌套子查询(WITH, INLINE VIEW)等等，并不是改个WHERE那么简单。

"模板是运行时需要的，甚至开发时可以不出现 如1楼。"
依靠模板运行就要损失性能了，如果一个模板被大量使用你还要考虑做模板的CACHE。我倾向于利用模板生成静态的程序，就是那些有一定模式可循的代码。这样代码量增大了但性能更高。
另外你的模板都是对应一个表的吗？多表连接怎么处理的？

"那里边的例子就是DTO出现前的SRM程序，包的不严，最多算是个睡裙。DTO就是阿拉伯长袍了，还露一个where的小脸蛋。DAO就戴上面纱，我们的ORACLE美女可就一点见不着了，真是让人不爽。你就专心看她的拿手菜，就别老是心猿意马的想看人家的身体啦。"
甩掉DTO, 把DAO做到数据库里, 你才能发现ORACLE深层次的美。不入虎穴焉得虎子!

"我也是担心这个问题。这个逻辑是INFORMIX的，……"
我认为你们的系统基本上不用考虑INFORMIX和SYBASE了，要说DB2, SQLSERVER还有点希望。
这个问题如果用存储过程来解决，游标在存储过程中打开访问，用SELECT FOR UPDATE NOWAIT跳过被锁的行，简单得很。


"前边说了，如果解析一个结果集到结构，我仍需模板。此时，并不能保证存储过程里的sql与我的模板一致。"
那就自己用OCI写一个工具生成模板了（或干脆是生成最终代码）。
不一致又会怎么样呢？像我写存储过程，大多数情况的修改是增加输出列，旧的前台程序即使不用这些新增列也不会出错。


"况且，你在存储过程里，结果集要重新筛选过（我发表的程序只是DEMO，并非完整的，其中还有筛选算法略去），选中的席位占用、打包输出。你如何重新组织结果集？用临时表吗？效率要比我低了吧？
我的DTO_prepare()要简单多了吧？还能保证语句结果集和struct的一致。C程序的处理能力要比那半编译的存储过程高多了，灵活多了吧？"
不知道你这筛选什么意思；不知道为什么要重新组织结果集，更不知道为什么用临时表。你把数据结构和需求贴出来，我来写一段PLSQL看看。当然不包括DTO_toJSON，格式化不是数据库干的。


"前边说了，我们是三层 C/S应用，不允许客户端访问数据库的。广义的讲，我这里就是存储过程了，不过不是数据库的，是C的。"
对我来说应用服务器就是客户端, 我要让它尽可能的瘦, 只管输入输出。你把直观的数据库操作拆成DAO, DTO, 一个事务要和数据库多次交互，中间还混杂着模板的解析，效率比起数据库的存储过程要低得多。


"没有浪费，几乎所有功能都可以实现，只不过更简单了。"
你想不想自己实现分析函数和CONNECT BY? 能比ORACLE做得好? 还更简单?


"虽然有潜在的换数据库的意图，但不是主要的，主要是把数据库与应用割裂开，让精英处理数据库，草根处理应用。"
既然换数据库不是目的，你们老总的规定就有些莫名其妙。数据库是整套系统的核心部件，是整个方案的一部分，和应用是不可割裂的。虽然我前面也说过要在前台程序消灭SQL, 但只是为明确分工而已，其实整个团队包括QA人员都应该掌握一定的数据库知识，用SQL制造一些测试数据、查看测试结果这是很起码的吧。


"另外提供一些工具，方便数据打包和格式变换工作，用于支持数据传输。"
这个我十分赞同，确实是在数据库之外完成的工作。利用存储过程和这个没有矛盾。


"按记录访问数据库也是一个目的。自从SQL出现后，没办法按记录和struct操作数据了。"
SQL的中心思想就是集合操作。比方说能用一个SQL UPDATE的一批数据，就不要先用游标读出来再逐行写回去。按记录访问是要尽量避免的。

"这个项目在这里提出来，可能就是反对的多，因为在这混的大多是精英，可是，你们想过草根的痛苦吗？"
我国的精英应该是不写程序的 如果把数据库神秘化给人造成SQL很难掌握的误解，我们就要更大力普及数据库知识。

sunfly1983

数据库大师pk编程大师
过来学习！

azhou2000

两种方式的实现都有各自的道理：
1. 从老板的角度讲，当然希望实现深层的封装与隔离变化，以便节约成本，快速应对变化；
2. 从技术人员的角度来讲，当然希望自己不要成为像农民工一样的没有技术含量的人；
不过主动权在老板的手里，未来的普通开发人员必将像白菜一样。

sunfly1983

原帖由 zhangfengh 于 2008-11-26 09:30 发表


老板只管拍脑袋，遭罪的都是技术人员

如果完全不用数据库的优势，都封装好的话，可以考虑不用数据库了，直接写文件保存就是了，还可以省去数据库方面的费用

赞同，数据库开发人员不然就被抢饭碗了！

yulihua49

原帖由 azhou2000 于 2008-11-26 09:07 发表
两种方式的实现都有各自的道理：
1. 从老板的角度讲，当然希望实现深层的封装与隔离变化，以便节约成本，快速应对变化；
2. 从技术人员的角度来讲，当然希望自己不要成为像农民工一样的没有技术含量的人；
不过主动权在老板的手里，未来的普通开发人员必将像白菜一样。

那我是助纣为虐啦！
现在，名称改为DAU--Data Access Utility.提供的方法，如果是数据对象，如seat_DAU就是Data Access Unit。
就是一组按照数据单元访问数据的工具，在C语言，就是结构，JAVA就是对象，二者之间就是JSON对象。
不仅提供按单元访问数据库，还可以按单元交换数据，数据源可以是数据库、网络数据源、文件（二进制记录文件，顺序文本文件、XML文件、TPF等）。
有意思的是：
TUXDEV表和TUXCONTEX表，不少列是同名的，现在要把二者同名字段赋值，可以：
ret=DAU_copy(&tuxcontex_DAU,&tuxdev_DAU,0);//tuxdev -> tuxcontex ,全部同名字段。

ret=13，复制了13个字段，类型格式自动转换。
当然有人说select也可以，但tuxcontex还有其他内容，select不方便。
后边又一句：
ret=DAU_copy(&tuxcontex_DAU,&tuxuser_DAU,0);//tuxuser -> tuxcontex ,全部同名字段。
又复制5个字段，完成了数据组装，方便吧？
。。。。。。再组装点别的，然后:
DAU_insert(&tuxcontex_DAU,buf)；//写入数据库
一个SQL也没有，大家感到很失落吗？可是那个insert into语句有什么诱人之处吗？我是烦死了，不写更好，我不怕人说没技术含量。

还可以提供很多单元操作工具，这在过去是不可能的。
现在，用DAU写服务器，已经获得巨大好处，DAU灵活的数据转换和严格的边界控制，极大减低了C语言内存溢出的风险，使服务器的可靠性、坚固性有极大提高。

下一步的改进就是适应多种数据源，那就不能绑定SQL_Connect,那太局限了。准备设计DMO--DATA Manipulate OBJECT,是真正的对象，包括数据源和操作数据源的方法。

这个工具的用途在于，如果你是一个软件公司，开发了一个产品，比方使用了ORACLE数据库。当你推广给用户时，用户要求使用MYSQL，这个平台转换是很方便的。
当然，这个问题人家早解决了，用JAVA嘛！只有性能要求极高的系统才会用C，在C的世界，这还是一个新东西。

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

newkid

几天不见你露面，又做新产品出来了？

DAU_copy:
这是为你的思路服务的东西，如果是真正的瘦客户端，数据传递的层数是很少的。
退一步讲，即使我要用模板的方法，我也会用模板生成一系列静态赋值语句，在运行时是用不着模板的。你不是很在乎C的高性能吗？甩掉模板才会使性能更上一个台阶！
当然很少量的数据复制是可以用你的方法。

"可是那个insert into语句有什么诱人之处吗？我是烦死了，不写更好，我不怕人说没技术含量。"
当然有，INSERT摆在那里，以后数据出了错，很容易追踪到是从哪里进来的。隔着你的DAU, 这个追踪就困难了些。
INSERT还有更诱人的：我们可以INSERT ... SELECT...（从一个复杂的查询获取数据，有这个就用不着你的DAU_copy了）
还可以INSERT ALL, INSERT FIRST, MERGE INTO, ...
哪一种都比你的C更高效，因为数据从来没有离开数据库。

"不仅提供按单元访问数据库，还可以按单元交换数据，数据源可以是数据库、网络数据源、文件（二进制记录文件，顺序文本文件、XML文件、TPF等）"
我曾问你如何解决表连接，你的程序员都把数据库表当作单个对象来处理吗？每一行数据当作一个“单元”？如果在数据库之外实现连接，我能猜到用的是类似NESTED LOOP的方法，本来一个SQL可以做到的，你不得不查询N次。
我还问你是否要自己实现分析函数，CONNECT BY，现在不得不降低一下门槛：是否连聚合函数（SUM, COUNT等）也要自己实现了？

"这个工具的用途在于，如果你是一个软件公司，开发了一个产品，比方使用了ORACLE数据库。当你推广给用户时，用户要求使用MYSQL，这个平台转换是很方便的。"
我不相信你们的售票系统会在其他数据库上部署。当推广一个系统时，数据库是不可分割的部分，数据库厂商是你们的战略伙伴。企业级应用的用户是不太可能拒绝使用ORACLE的。

yulihua49

原帖由 newkid 于 2008-12-2 23:26 发表
几天不见你露面，又做新产品出来了？

"可是那个insert into语句有什么诱人之处吗？我是烦死了，不写更好，我不怕人说没技术含量。"
当然有，INSERT摆在那里，以后数据出了错，很容易追踪到是从哪里进来的。隔着你的DAU, 这个追踪就困难了些。
INSERT还有更诱人的：我们可以INSERT ... SELECT...（从一个复杂的查询获取数据，有这个就用不着你的DAU_copy了）
还可以INSERT ALL, INSERT FIRST, MERGE INTO, ...
哪一种都比你的C更高效，因为数据从来没有离开数据库。

紧锣密鼓的搞这个东西，来到少了。
实际上我是边做DEMO边改进，现在要做DEMO和培训教材、文档等。

你这个问题我是料到的。实际上在我们的系统里肯定是我的方法最优。
程序太长，不便上传。大致过程如此：
读TUXDEV，要验证很多东西，如CA，许可权限，交接班参数，终端属性、票据参数等等，
然后读TUXUSER，验证口令，唯一性，权限属性等等。
经过一些其他认证处理，才形成会话上下文。那段程序就是这最后一步。
既然数据都已经在内存，而且是加工后的数据，当然不能简单的：
insert into TUXCONTEX  select TUXDEV
再
update TUXCONTEX select TUXUSER
至少这是两次IO吧？我一次就够了。

至于调试，这个系统以调试、优化方便为特征。
例如：
在PRO*C里：
insert into table values(?,?,?,?,?,?,?)
或
insert into table values（:a,:b,:c,:d,:e)

出现一个值越界或格式错，你能看到什么？
我的日志里就会出现一个完整的，带值的语句，容易分析，而且可以直接粘到sqlplus里执行。

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

yulihua49

关于存储过程，这次升级是禁止使用的，尤其是密集型事务中禁止。
上次被SYBASE坑的不浅，一朝被蛇咬，十年怕井绳。

在SYBASE存储过程里，按单元处理数据就是以临时表为单元，大量的临时表创建、删除造成系统表systables锁，大量进程等待。
现象是：作业峰值，终端响应非常慢，但系统不忙，无论CPU，MEM还是IO。
这是死症，无药可救。就是说，发生了堵车，无论你的车跑多快也没用。

这就是为什么不用存储过程，不用JAVA服务器，不用多线程服务器而采用多进程单线程C服务器的原因，是经过大量理论研究和压力测试的结论。
（多线程会在内存资源上互斥，尤其是内存分配释放时。JAVA的内存分配、垃圾回收太频繁了而且不可控，用于高密集度事务处理很危险）。
（去年12月，ORACLE与BEA耗巨资进行了大规模的压力测试）

想这样一些理论问题：
页锁、行锁、表锁哪个快？
多进程和多线程那个快？
单个任务测试和大量终端并发互斥测试结论是完全相反的。
至于JAVA、存储过程、C，那个快？
实话说也是上面那个问题。单个的任务其实速度差不多，C也快不到哪去（不过我敢保证C还是要快一点点），但在造成堵车现象的概率，C+多进程+细粒度互斥（行级锁）要低得多了。

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