看我做的数据库包装器

newkid

先来给你提一个设计上的意见：
母表的PRE_ID没必要用这种形式，把三个列分开来存，查询更方便。要合在一起可以用VIEW实现。
SEAT_REMANT表完全没有必要，实时从SEAT表中COUNT就可以，也可以做一个VIEW. 维护这个表的成本远远抵不上带来的收益。

双方都在运行中，不允许停止。比方一批席位从一个节点传送到另一个节点，双方都在作业中。数据中会有部分重码等等。

嘿嘿，我倒想问你怎么实现增量更新？你怎么知道哪些数据被增删改过了？
ORACLE有高级复制，DATA GUARD, 都是成熟、高效、强大的产品！

还有一种可能，双方不同数据库。比方现系统是SYBASE，新系统是ORACLE，DAU是完全胜任的。
只要需要，我很快就会把SYBASE和MYSQL，SQL SERVER，DB2的DAU写出来。

ORACLE跟异构数据库通讯可用透明网关。市面上ETL工具也很多，想不出有什么理由自己去做。

其实你跟我叫板，主要还是性能问题，也许，我的程序性能不如你，但要比很多二流程序员好。
你出程序的确很快，但世上这样的高手能有几个？身价几许？能说劳动生产率高吗？你那个程序不长，可是我现在还在迷宫里转呢。我都搞不清什么逻辑了，因为业务逻辑我清楚，那个不清楚的逻辑是什么逻辑我不清楚。
我的DAU程序员，如果对C略有了解，半天功夫就能培训出一大堆来。他们只需要简单的，面向过程的思维，就可以实现任何设计好的业务逻辑。
学10个函数包打天下，什么活都敢接。当然还有一堆utilily ’s，可用可不用。（哈哈，有点卖膏药的味，不过我不收钱，白给）

不仅仅是性能问题。我完全可以写出你那个风格的程序，但是我不愿意。你那种嵌套循环的写法，即使是我这样的老程序员，也要费点神才不会搞错。用SQL表连接，只要把连接条件、过滤条件丢给ORACLE就行了，至于它用NESTED LOOPS JOIN还是HASH JOIN我根本不用操心！计算全部在SELECT部分完成，一目了然。

c那个DAU程序，我写了不到400行，如果认真看，一般人1个小时基本能搞懂。（一帮孩子照它写TPF呢，苦阿）。
你的程序100行左右，我，哦别说我这笨人了，找个对PLSQL比较精通的吧，要看几个小时能明白？
原来见过一个ORACLE虫，写一个SQL4小时，调好用一周，经常的。
DAU，4个小时写的，一个小时调通，调对。
[/QUOTE]
只要你明白一点SQL的原理就很容易看懂了。这只是个习惯问题，我相信你很快就会习惯。

先来给你提一个设计上的意见：
母表的PRE_ID没必要用这种形式，把三个列分开来存，查询更方便。要合在一起可以用VIEW实现。
SEAT_REMANT表完全没有必要，实时从SEAT表中COUNT就可以，也可以做一个VIEW. 维护这个表的成本远远抵不上带来的收益。

双方都在运行中，不允许停止。比方一批席位从一个节点传送到另一个节点，双方都在作业中。数据中会有部分重码等等。

嘿嘿，我倒想问你怎么实现增量更新？你怎么知道哪些数据被增删改过了？
ORACLE有高级复制，DATA GUARD, 都是成熟、高效、强大的产品！

还有一种可能，双方不同数据库。比方现系统是SYBASE，新系统是ORACLE，DAU是完全胜任的。
只要需要，我很快就会把SYBASE和MYSQL，SQL SERVER，DB2的DAU写出来。

ORACLE跟异构数据库通讯可用透明网关。市面上ETL工具也很多，想不出有什么理由自己去做。

其实你跟我叫板，主要还是性能问题，也许，我的程序性能不如你，但要比很多二流程序员好。
你出程序的确很快，但世上这样的高手能有几个？身价几许？能说劳动生产率高吗？你那个程序不长，可是我现在还在迷宫里转呢。我都搞不清什么逻辑了，因为业务逻辑我清楚，那个不清楚的逻辑是什么逻辑我不清楚。
我的DAU程序员，如果对C略有了解，半天功夫就能培训出一大堆来。他们只需要简单的，面向过程的思维，就可以实现任何设计好的业务逻辑。
学10个函数包打天下，什么活都敢接。当然还有一堆utilily ’s，可用可不用。（哈哈，有点卖膏药的味，不过我不收钱，白给）

不仅仅是性能问题。我完全可以写出你那个风格的程序，但是我不愿意。你那种嵌套循环的写法，即使是我这样的老程序员，也要费点神才不会搞错。用SQL表连接，只要把连接条件、过滤条件丢给ORACLE就行了，至于它用NESTED LOOPS JOIN还是HASH JOIN我根本不用操心！计算全部在SELECT部分完成，一目了然。

那个DAU程序，我写了不到400行，如果认真看，一般人1个小时基本能搞懂。（一帮孩子照它写TPF呢，苦阿）。
你的程序100行左右，我，哦别说我这笨人了，找个对PLSQL比较精通的吧，要看几个小时能明白？
原来见过一个ORACLE虫，写一个SQL4小时，调好用一周，经常的。
DAU，4个小时写的，一个小时调通，调对。

只要你明白一点SQL的原理就很容易看懂了。这只是个习惯问题，我相信你很快就会习惯。

程序还是没转出来，关键是许多操作不懂，MERGE要先学，nvl原来就似懂非懂，trunc（）是什么？等等。view里的数据何时可用？都有些什么？好像是些非过程的东西，拿过程思维老是转不过来。

这个程序很好懂的。你先往参数表插入一行查询条件，注意不要COMMIT, 它是临时表，提交完数据就没了。
然后你可以SELECT * FROM VW_TRAIN, 或VW_SEAT, 或把里面的每个子查询单独拿出来运行，看看结果。就是一些表连接而已，和你的嵌套循环结果是一样的。
NVL, TRUNC 都是很基础的东西，就看你愿不愿意花几分钟去了解一下。
VIEW是一个定义好的查询，SELECT * FROM VIEW就相当于执行了那个查询。它只是个逻辑上的空壳子，可以把复杂的查询模块化。
还有什么看不懂的就提出来，我说到你懂为止，就怕你不耐烦呢！

newkid

原帖由 cuicg 于 2009-3-7 08:31 发表


我对newkid的敬佩肯定是毋庸置疑的！

我再说说我的看法：

你的oracle水平对我来说无疑是难以望其项背的，但不能把你的标准强加给别人，我绝对承认你的思路和方法。但就好像学化学时老师提到的“实验室方法”和“工厂方法”。
你的这些对开发人员要求太高，我认为暂时是无法普及的！如果让开发人员采用这种方式，就需要让他们学习十年的oracle理论才能干活。

我在前年有大约一年的时间负责公司J2EE架构的开发工作。我选用的开发框架必须要满足以下原则：
1、开发速度要保证
2、最终性能要保证
3、维护起来要简单

我现在开始考虑快速开发也必须要满足以上这些原则！

呵呵，MM过奖了，我就是熟练而已，这是多年经验磨练出来的。
关于快速开发我没有发言权，我一直都是用文本编辑器的手工作坊方式，但是开发速度从来不是我的问题，把需求吃透，作出良好的数据结构设计才是重点。

cuicg

原帖由 newkid 于 2009-3-8 03:44 发表


呵呵，MM过奖了，我就是熟练而已，这是多年经验磨练出来的。
关于快速开发我没有发言权，我一直都是用文本编辑器的手工作坊方式，但是开发速度从来不是我的问题，把需求吃透，作出良好的数据结构设计才是重点。

能描述一下您的工作内容么？我当然不是窃取商业机密，呵呵
是40%的时间做需求，40%的时间做PL/SQL的开发，20%的时间调试？
我猜的对么？

yulihua49

原帖由 nyfor 于 2009-3-7 21:31 发表

(好像楼主说是你们单位数据库知识最强的吧?)

nonono
我们单位有很多比我强的，不过他们都玩JAVA，一定要把JAVA那套（至少是思想）套到C，至少TUXEDO服务器层是C的。
我很愿意向各位学习，需要时间。
系统性能有时也不完全是执行时间。这在以后会有一个时间金字塔分析方法。
我非常同意大家的建议，那个余额表建立视图较好。
席位库的on_date可以改为YYYY-MM-DD,上车时刻可以在别处计算。
view的条件是seat.flag=0,而且，被其他进程锁住的、未完成事务的记录不包含在内。
时间金字塔是这样的：
客户端是0层，TUXEDO服务器是1层，数据库引擎（RAC）是2层，存储装置是顶层。层与层之间是网络。

存储                                                            －
                                                               /     \
RAC                                                   ----         ------
                                                       /                       \
TUXEDO                            -----------                          ----------
                                       /                                                     \
client           ---------------                                                         ----------------------

client的消耗与系统吞吐量无关，不分析了。

下边的数据是加载程序测的：
real    0m1.320s
user    0m0.308s
sys     0m0.096s
在TUXEDO这一层，消耗了0.404CPU,其余0.916,有一部分在TUXEDO层，其余是RAC以上层。
在实际业务中，有时这部分占80％以上。如果CPU主频没什么长进，这个时间很难缩短。
TUXEDO层具有无限可伸缩性，可以无限制增加该层服务器的数量（多核、多CPU、多机）。这部分性能可以线性、超线性的增长。
RAC层具有有限的可伸缩性，一般8个节点以上提升速度就不快了。
所以，在我们的架构里，TUXEDO层的性能可以得到较多利用，使有限的RAC层可以为更多的客户端服务。
而存储过程就把全部负荷加到RAC层。
实际上，DAU的性能在存储过程同数量级，不相上下或略慢，这没有关系，在其他方面会得到补偿。
ORACLE，我承认有很多东西要学，但更多的人有更多的东西要学。开发一种工厂化的生产工具至少在我们这是非常必要的，
它使相对廉价的劳动力能够生产出经济适用的，有时也很优秀的产品。况且，DAU已经成型了，基本得到同仁的认可。

[ 本帖最后由 yulihua49 于 2009-3-8 14:54 编辑 ]

cuicg

原帖由 yulihua49 于 2009-3-8 11:25 发表

nonono
我们单位有很多比我强的，不过他们都玩JAVA，一定要把JAVA那套（至少是思想）套到C，至少TUXEDO服务器层是C的。
我很愿意向各位学习，需要时间。
系统性能有时也不完全是执行时间。

菜鱼是问，你是不是你们公司数据库最强的！

newkid

原帖由 cuicg 于 2009-3-8 07:42 发表

能描述一下您的工作内容么？我当然不是窃取商业机密，呵呵
是40%的时间做需求，40%的时间做PL/SQL的开发，20%的时间调试？
我猜的对么？

有什么机密，不就是打工么
我们网站是做在线游戏的，我做的是数据库部分，管理玩家的积分、比赛结果等。因为有些游戏可以玩钱，还要做在线支付部分。
我在需求+设计部分大约花70%的时间，剩下30%是开发和单元测试。再细分的话都是一半一半吧。
设计结束后我已经写出了CREATE TABLE语句和过程的接口，代码要怎么写心理有数，开发时间就很少了。高峰时一天写几千行是家常便饭，当然要感谢ULTRA EDIT的强大的编辑功能！

chengboxian

原帖由 newkid 于 2009-3-8 23:27 发表

有什么机密，不就是打工么
我们网站是做在线游戏的，我做的是数据库部分，管理玩家的积分、比赛结果等。因为有些游戏可以玩钱，还要做在线支付部分。
我在需求+设计部分大约花70%的时间，剩下30%是开发和单元测试。再细分的话都是一半一半吧。
设计结束后我已经写出了CREATE TABLE语句和过程的接口，代码要怎么写心理有数，开发时间就很少了。高峰时一天写几千行是家常便饭，当然要感谢ULTRA EDIT的强大的编辑功能！

一天写几千行? 神人啊。我最多写六七百行

wm_qz

哈哈东西是好，本人自己写了一套C#的，包括数据库的操作，接口，可以生产JAVASCRIPT对象，AS3对象 c#对象，vb.net的都有，包括前台，后台，接口层都有

losebird

好像有点复杂。。。

losebird

学习了。。。