「なぜSQLを書きたいのか」を考えていた時に、直接的表現でSQLを書きたいと言われた
わけではないけれども、おそらくこういう時に「もしもSQLが書けたなら…」と思うだろうな、
と想像されたのが「任意選択をしたレコード帳票に出力したいとき」です。
任意選択というのは、WorkWithなどで一覧表示したレコードの中から複数を選択して、
それに対して何かする、一般的にイメージしやすいのはSNSにアップしたりメッセージに
貼り付ける写真を選択するようなケースですが、業務システムの場合は帳票出力対象を
選択させるケースでよく見られます。
このインターフェースはWorkWithでは簡単に実現できます。MultiRowSelectionプロパティを
設定するだけです。そうすると、ボタン操作などのアクションをしたときに選択されたデータの
入ったSDTコレクションが自動でパラメータに渡って来るので、それをプロシージャなどで
受けて帳票なりバッチなりを実行させればよいのですが、ここになかなか気づきにくい
問題点があるのです。
まず、渡されるのが「WorkWithに定義されている項目が含まれるSDT」であるので、
当然ながらWorkWithに含まれない項目はロジックを記述して取りに行かなければならない。
さらに問題となるのはそれが複合キーである場合です。
複合キーが複数件選択されているので、それを元にさらに別項目をテーブルから取得しよう
とすると、OracleならばIN句に複合キーを記述できますが、GXは様々なDBMSに対応する
必要があるため、その記述はサポートされていません。となると、選択されたSDTを
ループさせて一件ずつテーブルアクセスを行うロジックを作らなければならなくなります。
選択するのは人間なので、さほどパフォーマンスに影響するほど大量レコードにはならない
はずですが、特にそのロジックと並行していろいろなことをやっているとそれなりに遅くは
なってしまいます。これは、そもそも構造を変更して必要な項目はWorkWithに非表示ででも
含めてしまえば回避できます。
次に、やはり渡されるのがSDTであるため、「HTTPのパラメータにはテキストしか渡せない」
という至ってシステム的な制限にどうしても引っかかるということです。
これはセッション変数に退避したり、JSONでテキスト化したりと簡単に回避できる制限なの
ですが、GXが対象とする、「非専門の開発者」にとっては意味不明な制限と回避方法であり、
なんで自動でやってくれないのだろう、と思うところです。
さらに、一番目に見えて真っ先に指摘される問題点として、「選択はページごとにしなければ
ならない」というのがあります。1ページ目で何かを選択したとしても、ページ切り替えをして
2ページ目に移ると、1ページ目で選択したものは覚えていてくれない、というアレです。
これに関しては「簡単な回避方法」はなく、極めてゴリッゴリに作らなければ解決できません。
これらの問題点には改善の要望は出されているのですが、実現には時間がかかるだろう
ということで、一旦立ち止まって「なぜ複数選択をしたいのだろう?」というところに戻って
考えてみます。
そもそも業務システムで、担当者が「任意に複数選択する」というケースは、以前挙げた
「任意の日付間の集計値を出す」のと同様、ほとんどないのではないでしょうか?
大概は閾値のような条件があり、それに合致したものを選択するか、グループのような括り
があり、それに含まれるものを選択するか、その組み合わせになるはずです。
それでも任意選択インターフェースを導入したいのは、単に「旧システムのインターフェース
がそうだから」とか「工数が膨らむからいろいろな条件に対応できる画面にしたいから」という
消極的理由ではないのかと邪推してしまいます。
画面数が直接工数に影響しない、加えて画面インターフェースから考えるととたんに工数が
膨らむ、という特性を持つGXでは、上のような場合もまず「何をしたいのか」に戻って考える
方が、全体的な工数、特に保守を含めた工数は低減されるのです。
なので「設計変更を恐れてはならない」のです。
また、どうしても任意選択をさせたいケースとして、それこそ写真を選択するケースのように
担当者の「目検」や「主観」が重要になることも全くなくはないため、その場合は最近の
傾向を取り入れ、「お気に入り」や「買い物かご」のようなインターフェースとして、DBに
一旦保存するというのも一考かもしれません。