[开源]C结构体工具DirectStruct，更新至v1.3.0

yulihua49

BetonArmEE 发表于 2014-10-13 13:50
回复 38# yulihua49

见4楼：
http://bbs.chinaunix.net/thread-4156642-1-1.html
你这个帖子我有点晕，不知回到哪了。

yulihua49

BetonArmEE 发表于 2014-10-13 13:46
回复 37# yulihua49
DBVLLIST_userinfo是自动生成的宏。

    泛化函数在运行处理时会否性能损失？泛化函数是否会不够灵活，比如在复杂SQL的表达上？
    我的DirectStruct在解决以上第一点时因为是直接生成特化代码，运行的也是特化代码，所以直接、简单、高效。在解决第二点时，推荐应用弃用SQLACTION功能，直接用ESQL来实现表达复杂SQL，但其中的很多冗余代码（如字段名列表）都还是可以直接调用自动生成的代码片段来避免繁琐的手工编码。

处理好了，性能损失可以忽略不计。
灵活度不由函数决定，由模板决定。

SDBC使用OCI，CLI和数据库的直接接口，今后支持ODBC。效率比PRO*C要高一些，测试过一个例子大约是2.5倍的性能。

在模板里你通常可以看到列名、表名，殊不知，它是列表达式，表表达式，所以可以写出任意复杂的SQL，如：
TEMPLATE cube 6
unit:=CH_CHAR 9
(select tabname from $DB.dict where tabname=:tabname) tabname:=CH_CHAR 9
flg:=CH_SHORT
count(*) count:=CH_INT
sum(dat1) s:=CH_INT64
avg(dat1) ag:=CH_DOUBLE
tjrb    tjdate|unit|tabname|flg|
>mktpl
输入元数据文件名： tcube.meta

T_PkgType cube_tpl[]={
        {CH_CHAR,9,"unit",0,-1},
        {CH_CHAR,9,"(select tabname from $DB.dict where tabname=:tabname) tabname"},
        {CH_SHORT,sizeof(short),"flg"},
        {CH_INT,sizeof(int),"count(*) count"},
        {CH_INT64,sizeof(INT64),"sum(dat1) s"},
        {CH_DOUBLE,sizeof(double),"avg(dat1) ag","%.2lf"},
        {-1,0,"tjrb","tjdate|unit|tabname|flg|"}
};

extern T_PkgType cube_tpl[];
typedef struct {
        char unit[9];
        char tabname[9];
        short flg;
        int count;
        INT64 s;
        double ag;
} cube_stu;

yulihua49

BetonArmEE 发表于 2014-10-13 14:16
所以说，工具之间有交集，也有相当大的差集，需求不同，应用场景不同，采用的设计和接口风格也不同，即使相 ...

我还不知道这个平台。
登陆了，建立一个SDBC账户，还没有干什么。

同意。。。。
我看出来，你在这个领域很多年了，我也是做这类软件多年。不然的话，不会对这个问题有如此深入的思考。
所以，与你交流才有知音的感觉。

yulihua49

BetonArmEE 发表于 2014-10-13 14:32
回复 43# yulihua49

我更懒，根本不想写SQL，所以让工具框架去写。

1. 
   
2. 
   
3. //插入一个表
   
4. 
   
5. static int insert_a_table(T_SQL_Connect *db_conn,FILE *xfd)
   
6. {
   
7. char cols[4096],stmt[4096],*p,*savep;
   
8. char *tabname;
   
9. int ret,i,n;
   
10. t_node node;
    
11. ctx_stu ctx;
    
12. T_Tree *cols_list=NULL;
    
13. SdbcDAO *dao;
    
14. //取出表名、列名
    
15.     if(NULL==fgets(cols,sizeof(cols),xfd)) {
    
16.           ShowLog(1," 没有数据!",__FUNCTION__);
    
17.           return -1;
    
18.     }
    
19.     TRIM(cols);
    
20.     tabname=strtok_r(cols,":",&savep);
    
21.     if(!tabname) {
    
22.           ShowLog(1,"%s: tabname is emypt!",__FUNCTION__);
    
23.           return -1;
    
24.     }
    
25.      
    
26.     strupper(tabname);
    
27.     try {
    
28.         dao=new SdbcDAO(db_conn,tabname);
    
29.     } catch( ... ) {
    
30.           ShowLog(1,"%s:%s Table not found!",__FUNCTION__,tabname);
    
31.           return -2;
    
32.     }
    
33.     dao->Data_init();
    
34.     ctx.dp=dao;
    
35.     node.n=0;
    
36. //生成加载列名表
    
37.     while(NULL != (p=strtok_r(NULL,",",&savep))) {
    
38.         if((255&*p) <= ' ') break;
    
39.         node.tp=dao->getTemplate(p);
    
40.         if(!node.tp) { //这个列的数据将被跳过
    
41.           ShowLog(1,"%s:%s column [%s] not found!",__FUNCTION__,tabname,p);
    
42.         }
    
43.         node.n++;
    
44.         cols_list=BB_Tree_Add(cols_list,&node,sizeof(node),node_cmp,NULL);
    
45.     }
    
46. //加载数据
    
47.     char gbkbuf[4096];
    
48.     for(i=0;fgets(stmt,sizeof(stmt),xfd);i++) {
    
49. /*
    
50.         if(has_cc(stmt)) {
    
51.             ret=utf8togbk(stmt, sizeof(stmt), gbkbuf, sizeof(gbkbuf));
    
52.             ctx.data=ctx.p=gbkbuf;
    
53.         } else {
    
54.             ctx.data=ctx.p=stmt;
    
55.         }
    
56. */
    
57.         TRIM(stmt);
    
58.         ctx.data=ctx.p=stmt;
    
59.         ret=BB_Tree_Count(cols_list,&ctx,fill_cols);//每列值按列名定义的次序填充到dao。
    
60.         *stmt=0;
    
61.         ret=dao->insert(stmt);
    
62.         if(ret<0) {
    
63.             ShowLog(1,"%s:insert %s fault,i=%d,err=%d,%s",__FUNCTION__,stmt,i,
    
64.                     db_conn->Errno,db_conn->ErrMsg);
    
65.             break;
    
66.             i--;
    
67.         }
    
68.     }
    
69. 
    
70.     BB_Tree_Free(&cols_list,NULL);
    
71.     delete dao;
    
72.     return i;
    
73. }

复制代码

完全泛型，只处理了文件中第一行第一列，是个表名。通篇没有SQL语句。但是，那个stmt，在插入第一条记录时，会有一个语句。后来就没有了，只是用游标，绑定变量进行操作，语句只解析一次，所以效率极高。
26行，特化dao为一个表，这个比较费时间，大约需要几毫秒至几十毫秒，但是只做一次，这对于要加载的数据量而言微不足道了。
但是在做OLTP时，这个开销就很可观。所以在OLTP环境，我们尽量事先生成模板，并显式的使用结构。
这里也可以看出，我们既需要序列化/反序列化功能，也需要数据库映射功能。
对于SRM，相当于JAVA的两种ORM:你的方法，类似于ibatis，我的类似Hibernate。都有自己的应用场景。

大众推荐

1.粗略浏览了2位的帖子，还没有仔细看你们的东西的具体用途，初步感觉是，
A. @BetonArmEE 的偏向于不同语言之间的序列化（类似于google protocol buffer?而据说这个不支持C)，特别地，比较适合应用于网络传输？
B. @yulihua49 的偏向于不同语言之间的数据库操作？（其他方面暂时还没有仔细看）

2. 这段时间在实现一个APP的后台，是居于之前写的后台上修改的，主要的工作量在几个地方：
A.修改数据操作部分，占40%左右的工作量。之前用C来解析JASON，STRUCT <-->JSON 之间的代码改动最大。
B.数据库设计和操作，占30%左右的工作量。数据库<-->STRUCT的转换，改动很大。
C.其他流程/新功能改动，占30%左右的工作量。这个是针对新功能需求而改，几乎是无法避免。
D.以上改动的编码总时间大约不超过40个小时。

3.之前用C写了一个比较适应于短链接的服务器后台，貌似有如下优点：
A.单进程+线程池。自测比python tornado高效30%左右。
B.占用内存小，相对来说也比较稳定（上线1年还没有自动崩溃过，当然，不排除高压下长期跑，可能会发现有问题）。
C.自带部分DATA CACHE策略和管理。
D.新功能只需要添加一个call back就可以。也就是说服务器框架和具体的应用耦合比较小。

突发奇想，如果能把两位的优势也集合起来，貌似要实现一个：
A.运行高效
B.开发效率比较高
C.支持不同语言之间的数据传输
D.支持不同的数据库
的应用服务器，似乎并不是不可能的事情。。。。
下一个项目真的要好好看一下两位的作品了！

BetonArmEE 发表于 2014-10-13 16:45
回复 47# yulihua49

大众推荐

好像YY多了。。。还是先做事吧。。。