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の特徴が
生かされ、業務の変化に最大限に追随することができるようになるのです。
三人目に続きます。