なぜSQLを書きたいのか その３

SQLを書きたい3人目の人は、再帰検索を行いたいがGXはWITHキーワードを生成する

方法がないので直接書きたい、ということだそうです。

WITHキーワードはすべてのDBMSで実装されているわけではないため、GXでは採用して

いないらしいです。

この問題は確かに難しい。つまり例えば組織データがツリー構造になっていて、それに

付随する発注データを「自分が所属する組織配下」でフィルタリングしたい場合、普通は

どうするでしょうか？

一覧に、所属する組織とともに、以下のような形で表示させるのが一般的かもしれません。

A部の発注

○月×日　商品A　10個　xxx円　A社　担当○○　A部第一課

○月×日　商品B　20個　yyy円　B社　担当××　A部第二課

○月×日　商品C　15個　zzz円　C社　担当△△　A部

○月×日　商品B　30個　aaa円　B社　担当☆☆　A部第三課Xグループ

○月△日　商品D　80個　bbb円　D社　担当△△　A部

しかし、GXにおいて「素直に作らないで」これを実現しようとすると、WorkWithのドリルダウン

機能(Viewタブ)を使うしかありません。

つまり、次のような形になります。

A部の発注

○月×日 商品C 15個 zzz円 C社 担当△△ A部

○月△日 商品D 80個 bbb円 D社 担当△△ A部

　　　↓ドリルダウン(タブへリンク)

A部第三課の発注

(なし)

　　　↓ドリルダウン(タブへリンク)

A部第三課Xグループの発注

○月×日 商品B 30個 aaa円 B社 担当☆☆ A部第三課Xグループ

これでも受け入れてくれるユーザーならこれでいいですが、いかにも使いにくい。

したがって、ツリー構造を表すインデックスのような項目を作り、

A部＝1201

A部第三課＝4303

A部第三課Xグループ＝5719

という組織コードだとすると、A部第三課を「12014303」、A部第三課Xグループを

「120143035719」という値をその項目にセットしておく。そして検索時は検索したい組織コード

と前方一致するものをすべて表示すればいいのですが、それではインデックス値を

ユーザーが知っていなければならない。そんなことはまずありえず、知っているのは

通常の組織コードのみです。

したがって、例えばA部第三課配下を検索したい場合、

①4303を入力→②4303のインデックス値12014303を抽出→③前方一致で検索

という風に、間に物が挟まった検索になってしまいます。

「検索ボタン」が付いていればボタンが押されたときに②の作業をすればよいのですが、

GXデフォルトの状態では自動検索を行うため、変換するには検索条件内にプロシージャを

噛ませなければならず、例えばSQLのWhere条件に関数を挟んだ時と同じように

レスポンスが悪化してしまいます。

自動リフレッシュを止めてボタンを表示させたとしても、単なるWebPanelならば

問題ありませんが、作らない開発で推奨するWorkWithを使用している場合は変換ロジックを

記述すると自動生成対象外(赤マーク)になってしまうため、やはり検索条件にプロシージャを

噛ませるしかなくなります。

ここら辺はなんとかしてほしいところです。

ただしよく業務を考えると、このような検索が必要な場合というのは、ログインしたユーザーに

よって検索する組織は決まっているはずで、ログインと同時にインデックス値を予め取得

できるはずなので、それほど気にしなくてよいかもしれません。

なぜSQLを書きたいのか その２

SQLを書きたい二人目の人は、「GX、つまりfor eachは主キー以外で結合しようとすると

極端に遅くなる、だからSQLで直接Where条件を書きたい」と語りました。

主キー以外で結合とはどういう意味か？

よくきくと、データの確定前と確定後で管理番号が変わる場合があり、確定前は主キーである

項目Aで検索するが、確定後は属性項目である項目Bで検索するという。

項目Bは確定前には空欄(NULLではない)だが、確定後に管理番号が附番され、それが

一意になるのだそうです。

以下、このテーブルをXと呼びます。関連テーブルはYで。
関連テーブルの項目Cに確定前か確定後かのステータスが入っているとします。

通常、XとYをSQLで結合するにはWhere条件の中で項目CのステータスによってOR条件で

結合先をAとBに振り分けるだけでよいが、GXのfor eachでは「通常自動的に項目Aで

結合されてしまうため、わざわざサブルーチンか別プロシージャに分割し」項目AとBを

振り分けなければならない、サブルーチンやプロシージャはSQL文自体も分割されるので

何度もDBアクセスが発生し、遅くなるという寸法だそうです。

苦肉の策としてこのシステムではXとYをあらかじめ上記のようなステータス別に結合させた

DBビューZを用意しておき、それをリバースエンジニアリングで全く別の項目扱いで

取り込んでいるのですが、役割は同じなので同じような名称の項目が乱立して管理不能な

状態に陥っています。

この場合はそもそもステータスによって結合条件が変わるという設計自体を疑わなければ

ならないのです。確定前と確定後で枝番を変えるとかテーブル自体を分割するとか、

根本的に構造を見直さなければ、どんどん結合するだけのためのプロシージャは増え、

GX管轄外のDBビューは増え、典型的なスパゲティ化が進んでしまいます。

GX、特に作らない開発の設計では従来よりもシビアな業務分析が必要になるので、

一瞬面倒に感じるのですが、それをがんばってすることによって初めてGXの特徴が

生かされ、業務の変化に最大限に追随することができるようになるのです。

三人目に続きます。

なぜSQLを書きたいのか その１

GeneXusを使っていると、ユーザー会でのアンケート結果などを見てもそうですが、SQLを

書きたいという要望が非常に多いことがわかります。

SQLを書かなくても知らなくてもできる、というのがメリットの一つでもあるのに、なぜなのか。

私が直接話すことができた三人の人が三人とも異口同音に「SQLを書きたい」と言葉に

していたのでありますが、その背景を訊いてみますと本当は三者三様に別のことを

したかったのでした。

最初の人は、「なぜSQLを書きたいのか」と尋ねたところ、「GeneXusはグループ化が

できない、グルーピングしようとすると一々SDTに入れて手動で照合をかけなければ

ならない、今時そんな開発言語はきいたことがない」というお話でした。

続けて「どういうユーザービューでグループ化をしたいのか」を尋ねると、「日付別や部課別、

店舗別の実績を管理者がチェックするための集計表」とのことで、どうやら帳票の要件である

ケースがほとんどのようです。

この場合GXではSQLも手動照合も使う必要がなく、コントロールブレイク機能を使うことが

推奨されているはずですが、困ったことにコントロールブレイクとは何なのか、という資料が

つい最近までどこにもなかったのです。

その最近になってようやく公式のFAQ集にも掲載されたので、今ここで「それ何？」と

思われる向きはそちらを参照してほしいのですが、それまでは次のような状態でした。

コントロールブレイクについての有識者が、他の人が手動照合をしているロジックをたまたま

発見して、そんなことするより簡単な方法がある、ということで伝授するか、もしくは逆に
いつも手動で照合して面倒だなあと思っていた人が、たまたま有識者のロジックを見て

質問しに行く、というようにある種一子相伝のような状態だったのです。

したがって、知っている人は知っているが、知らない人は本当に知らないという、GXという

相当小さい世界の中ではありえない情報格差が生まれていたのでした。

コントロールブレイクは、特に一般の開発言語から転向した人にとってはパッと見とっつき

にくいですが、見慣れると、内側から外側に流れるSQLのグループ化よりはるかに

理解しやすいし、まして手動照合などという頭がこんがらかる前近代的な作業にはとても

戻れません。

帳票はこれでOKですが、画面はどうでしょう。

実はグルーピングが必要な画面、というか「ユーザービューとして考えて」グルーピングした

画面で何か業務をしたい要件というのはあまりなく、ほとんどがグルーピングした結果の

集計値を承認や締め作業のために画面で確認したい、という要件でしょう。

そしてもしおかしいところがあった時に初めて明細を表示させて確認する、このような要件の

場合は、集計パターンがきっちり決まっているので、以前の記事のように集計キーを

持たせてそれをWorkWith一覧画面で表示すればいい。クリックすれば自動でそのキーに

該当する明細のタブが表示できます。

一方で、私には経験がありませんがどうしても一画面でグルーピングしたい、という要件も

あるかもしれません。

実はそれもWorkWith、というかGridで対応でき、Grid.Loadイベント内でコントロールブレイク

させることができるのです。

「SQLを書きたい」という一言の中にこれだけの背景があるとは通常は考えないので、つい

「SQLが書けない→GeneXusは不便である」という結論に向かいがちであり、実際に

世間一般の評価もそうなっているようであるのは残念なことです。

二人目以降の「SQLを書きたい」人の話に続きます。