|
|
原帖由 newkid 于 2008-12-5 23:30 发表 ![]()
为啥数据库就不能用便宜的intel服务器作集群？
你不用存储过程，但是给数据服务器的压力一点也没有减少，反而更大，因为本来一次数据库交互（存储过程调用）变成了多条SQL。
有什么“数学计算”是在数据库之外进行更合算的？举个例子！
我先来一个例子：假如你有10万个员工，求工资总额，让数据库求和就是一个在10万行记录上的SUM。你也可以把这10万行取到你的应用服务器去求和。你觉得哪个更合算？哪个对数据库负担更重？
你在WHERE中不使用绑定变量，那才是真正的CPU杀手！
别忘了我的挑战书，我等着你给我出题呢。
你尽可以写sum函数啊，我的包装器没有禁止你写复杂的SQL语句，在列名里可以sum、avg、total。。。。order by ，group by
随便啊。看我前边的例子，decode我都写了，sum不是一样嘛。
T_PkgType sum_type[]={
{CH_DOUBLE,sizeof(double),"sum(ccc) sum",0,-1},
{-1,0,0,0}
};
int ret;
double sum;
DAU sum_DAU;
char stmt[2048];
DAU_init(&sum_DAU,SQL_Connect,"tabname",&sum,sum_type);
sprintf(stmt,"where aaa='%s' and bbb=%d",value_for_aaa,value_for_bbb);
ret=DAU_select(&sum_DAU,stmt,1);
DAU_next(&sum_DAU);
DAU_free(&sum_DAU);
printf("sum=%f\n",sum);
.........
看来简单语句优越性不大。虽然存储过程写起来比这简单，但我要调用它并bind返回值，语句会比这多，更主要的，程序员必须理解其中的机制，我这程序概念很少。
看了ORACLE的语句池，用常数完全可以的，它要求严格相等的语句，我完全满足这个要求。如果两个客户先后请求了同样的内容，语句分析完全可以绕过。语句生成开销几乎为0，不必考虑。
领导对小型机的印象已经根深蒂固，轻易不会改变。再说，小型机可以买到服务，一年只要花几百万，系统出什么事，人家立刻派技术人员现场处理，全部责任由厂家负，我们领导就没责任啦！
整个架构方案与ORACLE密切协商的结果，ORACLE承认OCI是最高效的接口，存储过程可能在特定条件下更有效。
新的DAU支持存储过程，但对存储过程还是要慎用。
使用方法：
调用存储过程，bind返回参数，如果有游标 则：
DAU_init(&_DAU,SQL_Connect,0,&struct,_type);//struct和_type要保证和存储过程里的SQL语句一致。
_DAU.cursor=返回的游标。
后边的处理都一样了。
至于具体业务，就看程序员认为哪个方便了。
压力测试比较复杂，已经在PRO*C测过，能够满足需求。这套系统的性能与PRO*C基本一样。
下周给你个功能，你试试吧。我主要怀疑你的存储过程万能论。
性能方面，我相信，如果数据结构设计合理，各种方式差不多。现有的DEMO已经表现了优异的性能。
我一直强调的是，本方法编程便捷。就像hibernate，尽管对它的性能有不少质疑，仍获得广泛使用。
有什么“数学计算”是在数据库之外进行更合算的？举个例子！
这不需要考虑，几乎所有的数学计算，C语言都要比存储过程快数量级的。以主频2.5G的CPU为例，一条指令仅0.4毫微秒，即每微秒2500条指令，C语言的语句对机器指令有限对应（一个语句对应有限条机器指令）。存储过程（我知道ORACLE可以使用C库，但我指的一般的存储过程）是半编译的，即使简单表达式，内部也具有复杂结构。计算速度能超过C的，只有汇编了。
小型机的主频一般不高，远比INTEL CPU低，造价又那么高，当然不合算。
认证加解密、压缩、格式变换（变量－JSON－字符串）、动态计算方法（比如票价计算，算法随时由业主提出，可能要用一些描述字典来表达），链表，树，图（径路计算）等，哪样存储过程也玩不转。
[ 本帖最后由 yulihua49 于 2008-12-6 19:07 编辑 ] |
|
楼主: yulihua49
IP卡
狗仔卡
楼主
显身卡
发表于 2008-12-5 23:30
发表于 2008-12-7 22:19