さあ。ドンドン書いていきましょう．
■前回まで
/* SQL分析用フォーマット */
typedef struct ST_SQL {
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; /* ソート項目 */
}
前回、色々な事を書きました。
が、すみません、更に少し書き足してます。
肝心なテーブル名を忘れてました。
何故128だの64だのって？
気にしないでください。別に150でも100でも良いのです。
更にORG、E、別名ってナニ？
ORGは正式名(日本語)
EはEnglish(物理名)
AはAlias付与後だと思ってください。
何故、+1する記載があるのかって？
気にしてはダメです。
そこは細かい問題です。
何故、ポインタ配列が1024個あるかって。
それは、カラム数上限の問題です。
データベースのカラム上限は、どのDBでも1024程度(例えばDB2では1012)です。
そして、文字列を意識するchar*項目ではないので、彼らについては+1する意味はない。
ふふふ。。。
プログラマしてる皆さん、普段、こういうの意識してないと、最終的に単価に響きますよ？
別にこの事自体は大した事はないのですが。
こういう意識の積み重ねは結局時給へ跳ね返る。
折角単価に反映しやすい仕事をしているのならば、その現場でNo1を目指せば、色々得です。
少なくとも、3年、そういう時期を過ごすのは大いにアリです。
その3年は、人生設計を変えるイベントになる筈です…。
更に、カラム編集文字列はそもそも…
ざっくりした事を書けば、「select」～「from」の間に存在する抽出対象カラム群を、すべて一つの変数に格納するつもりだったのですが。
コレ自体、和名・物理名・別名の3種の変換が必要だと言う事に気がつき(設計書上の表記の問題)、急遽追加に。
ちなみに何故、私が「抽出元は桁数指定で宣言し、カラムはポインター(*)で宣言したのか」わかる人はいるでしょうか。
ここは、プログラミング技術と言うよりも、設計上、ある程度常識的に「そうであろう」考え方に寄り添ったつもりです。
答えがわかる人、わからない人、聞きたい人。
それぞれ興味があれば、コメントしてくださいね^^
また、Strはかの業界一般的に「String」の略。(数値でもなく時刻でもなく、単なる文字列でOK)
(ちなみに、ここまでの記載をする以上、素人はもう、相手にしてません(スマン))
追加した青字部分は"from"句、これがなければＳＱＬとして成り立たない根幹の部分ですので。
短文ですが、あまりに出来が悪かったので、とりあえず。
今後の流れは
「この構造体は１つのselect文しか意識してない、従って大きなselect集団を1つのSQLは理解できないデータ構造」
これをどう解決するのか。
お楽しみに^^