SDTは構造を無視する

もう少し構造の話をしましょう。

件の帳票甲乙は、マスタの設計と全く乖離していたために、SDTを使ってメモリ上で照合・

集計をしながら出力する、というロジックを組まなければなりませんでした。

SDTはGXの重要オブジェクトの一つで、C言語なら構造体に当たるものですが、こいつが

なかなかの曲者なのです。

構造が全く乖離していてもSDTを使えば何とかなる、ということはSDTを使えば構造を無視する

ことができる、ということなのです。

しかも、一見して構造体やスタティック・クラスなどに似ているので、元々言語系PGだった

開発者には非常にとっつきやすい。あれよあれよという間にトランザクション以上にSDTが

KB内に増殖してしまいます。

トランザクションと違ってDBにアクセスしたり画面表示したりといった機能はないただの

箱なので、SDTを使って何かしようとすると必ずロジックが必要になります。

これは画面とDBが直結するトランザクションに比べてレスポンス悪くなる要因です。

またそのロジックも当然構造を無視したものになるので手動での照合・集計が発生し、

業務の変更にも追随しないのでスパゲティ化・ブラックボックス化が進行、ほとんど

いいことがない。

後でわかったことですが、プロジェクトNでは、このような実装になっている画面が

一時サーバーのメモリを占領したこともありました。これはユーザー会でパフォーマンス

チューニングの例として取り上げられたこともあるので、覚えている方も多いでしょう。

メモリ占領事件の時は、何とかチューニングしようとインデックスの追加、フィルタ条件の

厳格化、ストアドプロシージャ化まで検討されたこともあったようですが、なんてことはない、

構造変更をすれば解決したのです。

この後一つの中規模プロジェクトでの開発経験から、SDTはセッション変数関係や、

上下が反転するような特殊な帳票以外では使用禁止、としています。

なぜ構造で解決できないのか？

プロジェクトNに話を戻しましょう。

同プロジェクトでは帳票が約150種類あったのですが、大部分をGXネイティブの帳票機能で

賄っています。誰が言ったのかわかりませんが、GXは帳票が弱いということになっていますが、

「専用の帳票ツールに比較して」作るのが大変である、という意味で、例えばJavaネイティブに

作るのに比べたら断然簡単に開発できます。

それはいいとして、ある帳票機能の作り方について、GX経験の少ない開発者Aから相談を

うけたことがありました。その帳票甲は、マスタで指定した順番に従って明細と中分類・

大分類の合計値、最後に全合計値を出力する、というようなものでしたが、このマスタの

設計が酷い。

確か次のようなものでした。

帳票マスタ {

K帳票種類

-帳票名

 出力順{

  K連番

  -区分(大分類/中分類/明細の別）

  -コード（リレーションなし)

  -出力順番号

 }

}

明細データ{

 K連番

 -大分類コード

 -中分類コード

 -明細コード

 -値

}

つまり、「連番」は意味がなく、「区分」ごとの「コード」、例えば大分類なら大分類コードに

よる紐づけを行ったレコードの合計値を出す、「明細」なら「明細コード」による紐づけを

行ったレコードを合計しないでそのまま出す、しかも「出力順番号」に従った順番で、

という帳票開発者に死ねと言っているような仕様です。

さらにビックリすることに、その前に別のGXに慣れた開発者Bが、「同じようで少し違う」

別の帳票乙をピッタリこの仕様通りに「通常の開発言語と比較すれば相当早く」作っていた

ものですから、それ真似すればよいということで開発者Aに無茶振りされた、という経緯の

ようです。そして「少し違う」部分にかなり途方に暮れることになった、というのですから

たまらない。

本来なら、開発者Aがマスタの設計変更を提案するべきだったと思いましたが、もうできて

しまっているものは仕方がない、そのまま突き進むしかありませんでした。

例えばマスタは、下記のような設計だったらまだ納得できます。

帳票マスタ {

K帳票種類

-帳票名

 出力順大分類{

  K出力順番号

  -大分類コード

  出力順中分類{

   K出力順番号

   -中分類コード

   出力順小分類｛

    K出力順番号

    -明細コード

   }

  }

 }

}

なぜこんなに気づくのに時間がかかったか。

(1)まず管理者がマスタを先に作る開発者を割り当ててしまった

(2)マスタ開発者は既存のメンテ画面か顧客の思い付きベースの仕様をそのまま実装した

(3)開発者Bはその実装能力に自信を持っていたのでマスタの仕様通りに帳票乙を早く

実装することにパワーを使った

(4)開発者Aは帳票甲乙とマスタのあまりにも乖離した仕様に気づいたが、立場上帳票乙と

マスタの改変を口にできない

(5)私が代わりに口を挟めばいいのだがスケジュールを優先してスルーした

という多重構造になっていたのでございます。

このような例を見て、極端に言うと「誰か一人でも考えを切り替えられない人がいると

作らない開発は成功しない」という考えに至りました。

それと、今回はマスタ開発者vs帳票開発者でしたが(実際には対決していませんが)、他の

事例を見ると目に付くのがDB設計者ｖｓ開発者の対立です。

従来の開発では実装に入ってDB設計を変えることはまずないので、その思想でいると

構造変更に対しては非常に非情なる抵抗勢力が出てきます。

この辺りは体制の組み方をGX流に変えないといけません。

構造で解決こそGX最大の武器

さて、前回の「C 構造で吸収する」です。

ちなみに最近は「構造で解決する」と称しています。

これは、今までの開発方式だと、いろいろなデータストアやオブジェクトから必要なデータを

抽出し、ビジネスロジックを使って集計や照合を行いましょう、としていたところ、データの

配置と関連性でその大部分を賄ってしまおう、という発想です。

つまり、従来「開発者の利便性」のためだけに蔑ろにされがちだったRDBMSの参照整合性を

最大活用するのです。

一見、GXの一般的なプレゼンとセットで出てくる「データ中心設計」（DOA）のことかと思う

方もいるかもしれませんが、さにあらず。

GXは「データ中心設計」ではなく、「ユーザービュー中心設計」なのです。

ここで「ユーザービュー」というキーワードが出てきましたが、私見ではGX開発においては

一番基本となる概念のはずですが、そもそもキーワード自体がほとんど知られていない

という怖い状態になっています。

難しい説明を一切端折ると、GXプレゼンでよくつかわれる「WHATを入力すると、HOWは

自動で類推される」の「WHAT」に当たります。

それもG#流の解釈では、「WHO」(WHAT NAME)「WHEN」(WHAT TIMING)「WHERE」

(WHAT SEGMENT)を含んだWHATです。

つまり、誰がいつどこで何をしたいか、がわかればそこで使用されるデータならぬ

アトリビュートが判明し、おのずとデータ同士の関連性が決まる、ということです。

少し具体化すると、パートのおばちゃんが日々の実績Aを登録するのと、課の管理者が

月末に集計されたAを照会するのでは全くユーザービューが異なるわけですが、従来の

開発ではしばしば同じ画面が使われるのです。

確かに、DOAベースで正規化するとテーブルは一つになるから、ロジック側で集計するか

しないか、項目を表示するかしないか制御するということになりますが、GX及び作らない

開発ベースで考えるとこれは逆なのです。

「パートユーザービュー」と「管理者ユーザービュー」でそれぞれ必要なアトリビュートは

何かと考えた時に、「管理者ユーザービュー」では集計キーとなる課と月は必須となる

でしょう。

昔えらい人が言っていました、「キーを付けたっていうことはそのキーで集計したいんでしょ」

GXを知る前に聞いた言葉ですが、その時は強引だなあと思ったものですが、今では

非常に活用しています。その逆として…

「集計したいならそれをキーとして持っておくのは当然でしょ」

かくして、「パートユーザービュー」では、日々実績登録しかしないわけですが、日報月報

というように月を外部キーとして持っておくのが望ましいのです。

これで、「課」と「月」をキーとして持ったトランザクションではほぼ何も作らずに集計値を

表示する「管理者ユーザービュー」が完成するのです。

これを、DOAを齧った人は日（年月日）と月(年月）が重複するとしてひどく避ける傾向に

ありますが、このように「構造で解決」したほうが、画面とテーブルが直結し余計な

ロジックが入らなくなることによりレスポンスがほとんど減衰しないようになりますし、

コードを記述しないのでメンテナンス性も向上、条件分岐が最低限になるのでテスト

工数のスリム化も期待できます。

GXはDOAではない、これが「GXはデータ設計が不要」と言われる真の所以です。

何も設計しないのではありません。