[開源]C結構體工具DirectStruct，更新至v1.3.0

yulihua49

BetonArmEE 發表于 2014-10-13 13:50
回復 38# yulihua49

見4樓：
http://www.cesargiobbi.com/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