業務システム向けの開発基盤というものは、DBの設計方針に対して中立的であるべきだ。扱われるDBの構造について強い制約を求めるようであってはいけない。与件としての「静的なデータ構造」に対して「データを登録・加工するための手段」を与えるものが開発基盤の役割である。データ構造のあり方について必要以上に介入すべきではない。
具体的に説明しよう。たとえば、旧来のオフコン（業務システム専用マシン）上で業務システムが稼働していたとする（話を簡単にするためにRDBベースであるとする）。オフコンの保守契約を更改しないことが決まって、別の基盤に置き換えることになった。業務システムとしてはとくに問題はないので、基盤の切替だけで済ませたいとする（やや不自然な前提だがあり得ない話ではない）。つまり、DB構成はそのままで、それらを操作するアプリだけを作り替えることになる。そのための手段として以下の選択肢が考えられる。
１．ERPパッケージ
２．Java等の汎用言語＋フレームワーク
３．ノーコード・ローコード基盤
１の選択肢は真っ先に却下されそうだ。既存のDBをそのまま使うための機構は、ERPパッケージには事実上用意されていないからだ。データHUBのような仕掛けを介してパッケージと沿わせる手もあるが、大袈裟すぎるし、よほど似通ったDB構成でない限りは無理スジである。
２では既存DBを扱えたとしても、ORマッピング(ORM)に苦労しそうだ。ドメイン駆動設計的な美しいクラス構造を目指せば目指すほど、ORMに苦労する羽目になる。旧言語からの機械的コンバージョンという手もあるが、ユーザ企業はコンバージョンに関わった業者に命運を握られることになる。内部構造がわかりにくいため、自分たちで業務システムの保守ができなくなるからだ。２の選択肢はどうやっても厳しそうだ。
３のノーコード・ローコード基盤はどうだろう。これは製品毎に事情が異なるので、既存DBを扱えるかどうかをベンダーに問い合わせるしかない。次の３つの答のどれかが返ってくるだろう。
(A) 当製品では扱えません
(B) 多少の調整を施せば、当製品で扱えます
(C) そのままの形で、当製品で扱えます
(A)であればその製品はあきらめたらいいし、(C)ならば移行先としての有力候補とみなせる。微妙なのは(B)で、どのような調整が必要なのか確認する必要がある。ちなみに拙作のローコード基盤 X-TEA Driver は(B)で、既存DBのテーブルを扱うために次の条件が求められる。
・主キーを持っていること
・更新ロック用カウンターを持っていること
主キーのないテーブルというものは例外的なので、最初の制約は大きな障害にはならない。２つ目はいわゆる楽観的ロックのための制御項目で、更新トランザクションの独立性を保証するために欠かせない。とはいえ初期値はゼロでかまわないので、項目を追加することに面倒なところはない。
では、次の制約があるとしたらどうだろう。
・規定形式の単独主キーを持っていること
これはつらい。たいていの既存DBは複合主キーを含んでいるし、単独主キーであっても期待されているデータタイプ（LONGINT等）であるとは限らないからだ。無理に合わせるためには、それぞれのテーブルの既存の主キーを二次キーに差し替え、規定形式の項目を主キーとして組み込むといった作り替えが必要になる。さらに各テーブルに、参照先テーブルに新たに追加された主キーで参照するための外部キー項目を追加して、そこに値を設定しなければいけない。そのデータ移行プロセスのややこしさを想像できるだろうか（図１）。面倒であるだけでなく、データ構造がわかりにくくなるという意味でなんとも「痛ましい」ような改変に思えてしまう。
この問題は「基盤間でのDB移行の容易性」として、もっと意識されていい。ある基盤上で組み立てた業務システムを、別の基盤に移行することになった。その際にDB構造を保全できるかどうかということだ。
特に主キーはそのテーブルのレゾンデートル（存在理由）といってもいいほど重大な定義要素なので、その改変を強制する基盤は、データ移行が面倒なだけでなく、データモデルの維持が困難になるという点で問題があり過ぎる。テーブル数が10個程度であればどんなやり方でもしのげるが、一般に50個以上のテーブルを含む業務システムでは致命的と言わざるを得ない。
どんなに優れた基盤でもユーザ企業は永遠にそこに留まるわけではなく、そこから引っ越すことは常に想定内の事態だ。その際、旧基盤上のアプリは廃棄されることになるが、DB構造とその上のデータは蓄積された資産として、必要ならばそのままの形で継承できたほうがいい。その意味で、いかなるDB構造もそのまま扱える基盤、すなわち、DBの設計方針に関して中立な基盤をお勧めする。
