■まずは訂正。(青字で)
/* 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 JoinMthd[64]; /* 結合方法(join、サブクエリ、union等も */
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
}
同階層であっても、例えばそれがunion、union all、exceptなのかを識別できないと、設計書化できません。
しかし、わざわざ別項目化する意味もなさそうなので、結合に含めます。
階層自体は、KNo、KNosubで表現できているので、あと必要だったのは「集合句の場合、どの集合句なのか」である事さえこのデータモデルに情報として組み込めればよかったわけです。
■さて、データモデルが出来たところで、実装。
「SQLから設計書を自動的に作る」と言う作業は、コンピューターの仕組みから言えば、どういう仕組みが考えられるでしょうか。
①SQLを頭から読み込み、逐一分析する
②SQLを頭から読み込み、全て読み込み終わった後に、分析する
多分、この２つの手段以外に考える付くのは難しいでしょう。
①のメリットは、何度も読み直すことなく、その場で複雑な判断を行う事で高速化できる
②のメリットは、一旦全て読み込んだ後なので「どの様な分析方法を取れるかの裁量がある」
あと、これは技術的な事ですが
①はファイルから読み込みながら処理する
②はファイルを一旦全てメモリに入れてからメモリ内の操作をする
と言う違いがあります。
どの様な例外があっても、「また読み返せる、読み返しても速度を毀損しにくいのは②」です。
従って、一端の処理方式は「まずはSQL全体をメモリに放り込む」って所から始めます。
■今後の事も考えて、言語を変更かな。。。
Cで書くのが一番応用が利いて良いと、思ったものの。
設計書って殆どの場合がofficeベースなんですよね。。。
って事であれば、VBAで作ったほうがわかりやすいかもしれない。
少し検討。