/* SQL分析用フォーマット */
typedef struct ST_SQL {
int KNo; /* 階層No */
int KNoSub; /* 階層サブNo */
int LKNo[64]; /* リンク元階層No(最上位の場合、0) */
int LKNoSub[64]; /* リンク元階層サブNo(最上位の場合、0) */
char JoinMthd[64]; /* 結合方法(join、サブクエリ) */
char *JoinKey /* 結合キー */
char Crud[16+1]; /* "Insert", "Select", "Update", "Delete" */
int DistinctFlg; /* Distinct：有⇒1, 無⇒0 */
char *ColumnsStr; /* 抽出カラム文字列 */
char *ColumnsOStr[1024]; /* 抽出カラムOriginal(項目別) */
char *ColumnsEStr[1024]; /* 抽出カラムEnglish(項目別) */
char *ColumnsAStr[1024]; /* 抽出カラム別名(項目別) */
char FromOStr[128+1]; /* 抽出元Original */
char FromEStr[64+1]; /* 抽出元English */
char FromAStr[128+1] /* 抽出元別名 */
char *WhereStr; /* Where句の中身 */
char *GroupByStr; /* グループ化項目 */
char *HavingStr; /* グループ化前処理条件 */
char *OrderByStr; /* ソート項目 */
}
実は、このデータモデルだけでは色々無理な点がある。
それは「このモデルの各項目にどうやってデータを格納するのか」と言う手段。
ここをロジックに頼ろうと考えているのが私の思想。
例えば。
char *ColumnsOStr[1024];は1024もカラムを用意しても、どの様にカラム群を正確に分割して格納するのだろうか。
今後はこういう細かい点を「実装しながら」、データモデルの欠点を探っていく流れになる。
■事前に変えておく
一応気になっているところは「このデータモデルでは、たった１つのSQLしか表現できない」と言う事だ。
設計書は複数作る必要がある。
従って、このデータモデルを複数持つ構造体を用意できるに越したことはない。
つまり、こういう事だ。
/* SQL分析用フォーマット */
typedef struct ST_SQL {
int KNo; /* 階層No */
int KNoSub; /* 階層サブNo */
int LKNo[64]; /* リンク元階層No(最上位の場合、0) */
int LKNoSub[64]; /* リンク元階層サブNo(最上位の場合、0) */
char JoinMthd[64]; /* 結合方法(join、サブクエリ) */
char *JoinKey /* 結合キー */
char Crud[16+1]; /* "Insert", "Select", "Update", "Delete" */
int DistinctFlg; /* Distinct：有⇒1, 無⇒0 */
char *ColumnsStr; /* 抽出カラム文字列 */
char *ColumnsOStr[1024]; /* 抽出カラムOriginal(項目別) */
char *ColumnsEStr[1024]; /* 抽出カラムEnglish(項目別) */
char *ColumnsAStr[1024]; /* 抽出カラム別名(項目別) */
char FromOStr[128+1]; /* 抽出元Original */
char FromEStr[64+1]; /* 抽出元English */
char FromAStr[128+1] /* 抽出元別名 */
char *WhereStr; /* Where句の中身 */
char *GroupByStr; /* グループ化項目 */
char *HavingStr; /* グループ化前処理条件 */
char *OrderByStr; /* ソート項目 */
}
typedef struct ST_SQLS {
char *SqlFileName;
int FileCnt;
ST_SQL *st_sql
}
さあ、ここからがトライ＆エラーの始まりだ。
一旦は考えてみた。
何もないより100歩も1000歩も良い。