標準化：「クエリの散在をどう防ぐか」
言語は何でもよいのですが、クエリの散在をどう防ぐかという仕組みやルールが
必要になります。
FW を使うとFWで適用されないようなかなり簡易なレベルのクエリや逆に複雑な
レベルのクエリをどう散在させず管理するか。
いずれにしても発行出入口をひとつにする。
というルールが必要。
そして、決してソース内に他PGソースと同様に併記しないというルールが必要になる。
散在することのデメリットは、いうまでもなくメンテが大変なこと。
散在させないことのデメリットは、書きにくさと可読性にある。
特にトルクに近いもので作るクエリ生成エンジンは、
・エンジン用生成クエリ
と
・勝手に書いたクエリ
が混在する可能性がある。
で、ちょっと今そこ悩んでます。
ExcelVBA用FW内で構文解析または構文作成をするクエリエンジンを
つけているのですが、例えば
SELECT A.COLUMN FROM TABLE_A AS A WHERE A.ID='AAA'
なんて、読んでもわかりやすいものをわざわざFWの
dim strSQL as stringstrSQL = makeSQL(Entity,ColNames,Values,TYPE_SRCH,strWhereDatas,StrWareColNames)
' Entity テーブル名
' colNames 取得カラム名群
' strWhereDatas 条件データ群
' strWhareColNames 条件カラム群
なぁんて呼び出すのもバカらしいと感じることはある。
これが大規模開発となると当然、最初の直クエリを書き出すヤツがでてくる。
これはクエリ書くヤツだけが悪いのじゃなくて、そういう標準化ルーチンを作ったやつも悪い。
とはいえ、成功していると思われるクエリ群はID=クエリの列挙ファイルにて
まとめてしまうという方法もかなり嫌がられているのも確か。
小規模ならよいが、スゴイ数なわけで開けど開けどクエリみたいなファイルが
IDEに並ぶことになる。
散在の問題は、かなり肝を据えて掛からないと失敗するか不満の温床になると
感じています。
（そんで、今自分がクエリ散在をさせようとしている・・・ぉいｗ）
追記：ちなみに散在をさせようとしてしまっている要因は、IN句です。
普通の検索ならよいが遅くてもINを使いたいときがある。
これを共通化させる場合、IN用に処理分ける必要がある。
ちょっと共通化して動いている部分を直すのが面倒なのです。
困ってしまいますね・・。
