もう少し構造の話をしましょう。
件の帳票甲乙は、マスタの設計と全く乖離していたために、SDTを使ってメモリ上で照合・
集計をしながら出力する、というロジックを組まなければなりませんでした。
SDTはGXの重要オブジェクトの一つで、C言語なら構造体に当たるものですが、こいつが
なかなかの曲者なのです。
構造が全く乖離していてもSDTを使えば何とかなる、ということはSDTを使えば構造を無視する
ことができる、ということなのです。
しかも、一見して構造体やスタティック・クラスなどに似ているので、元々言語系PGだった
開発者には非常にとっつきやすい。あれよあれよという間にトランザクション以上にSDTが
KB内に増殖してしまいます。
トランザクションと違ってDBにアクセスしたり画面表示したりといった機能はないただの
箱なので、SDTを使って何かしようとすると必ずロジックが必要になります。
これは画面とDBが直結するトランザクションに比べてレスポンス悪くなる要因です。
またそのロジックも当然構造を無視したものになるので手動での照合・集計が発生し、
業務の変更にも追随しないのでスパゲティ化・ブラックボックス化が進行、ほとんど
いいことがない。
後でわかったことですが、プロジェクトNでは、このような実装になっている画面が
一時サーバーのメモリを占領したこともありました。これはユーザー会でパフォーマンス
チューニングの例として取り上げられたこともあるので、覚えている方も多いでしょう。
メモリ占領事件の時は、何とかチューニングしようとインデックスの追加、フィルタ条件の
厳格化、ストアドプロシージャ化まで検討されたこともあったようですが、なんてことはない、
構造変更をすれば解決したのです。
この後一つの中規模プロジェクトでの開発経験から、SDTはセッション変数関係や、
上下が反転するような特殊な帳票以外では使用禁止、としています。