« ソフト開発に資材が要らないことの優位性 | トップページ | 問題領域とコンピュータの狭間で »

2014.05.19

DBMSの交換容易性と開発基盤

 最新のXEAD DriverでMS SQL Serverに対応した。これでJavaDB(Apache Derby)に加えて、Oracle, SQL Server, MySQL(MariaDB), PostgreSQLの4大DBMSに対応できた。テストに協力していただいた方々にあらためて感謝したい。他のDBMSについてもリクエスト次第で対応するつもりだ。

 これらに順当に対応できたのは、XEAD DriverがDBMSのごく基本的な機構だけを利用しているためだ。キーによる重複排除、インデックスによる並び替え、トランザクション制御といった基本的な機構だけが利用されている。データ型やSQLの「方言」にはそれなりに配慮してあるが、それ以外の固有性はほとんど無視されている。DBMSは標準機能をそなえた汎用的なデータストアとしかみなされていない。

 言い換えると、この開発基盤を使うのであれば、各DBMSに固有な機構は必要以上に使わないほうがいい。それらの作用が障害になることはないにせよ、定義様式が独特であるゆえに開発基盤から不可視になってしまうためだ。開発基盤というものは、システムを短時間で把握するための「見晴らしの良い書庫」であるべきだ。その内外を調べまわらないとシステムの振舞いを理解できないとしたら、可読性や保守性に問題がある。そうでなくても、特定のDBMSにロックイン(囲い込み)される恐れがある。

 DBMS毎に固有な機構を使わなくても支障はない。開発基盤上でテーブル定義がさまざまに拡張されているからだ。複雑なロジックをともなうバリデーションや仮想フィールドを組み込めるし、動的参照(*1)や異種DBMS上のテーブル同士の結合も簡単だ。多彩で魅力的なコスチュームが開発基盤によって提供されるので、その中身であるテーブル本体は「没個性な痩せっぽち」でかまわないのである。

 では、これまでなされてきたDBMS毎の機能拡充の努力は何だったのか。プログラム側で記述されていた仕様を、なるべくDB側に置けるようにする。すなわち、テーブル定義の拡張(インテリジェント化)が、DBMSの機能拡充の目標のひとつである。このことじたいは間違っていない。プログラム側の仕様が複雑であればあるほど、システム全体の保守性が損なわれるからだ。ところがテーブル定義拡張の個々の努力は、特定DBMSにロックインされるような余計な個性化を招きかねない。

 DBMS(RDBMS)というものは、半世紀前にE.F.Coddによってその数学的枠組みが提唱されて以来、すでに成熟したソフトウエア部品といっていい。こういうプロダクトについては多機能化や個性化など目指さずに、高速化、安定化、標準化、運用容易化をひたすら追及してほしい。気に入らなければいつでも他のDBMSに乗り換えられる、そんな交換容易な部品であればいい。

 そのいっぽうで、テーブル定義の拡張については、XEAD DriverのようなDSP(特定ドメイン向け開発基盤, Domain Specific Platform)が支援すればいい。テーブル定義をどのように拡張したら便利になるかは、ドメイン(適用分野)の特性によって違ってくるからだ。かくしてDSPは、DBMSの交換容易性を維持する役目を果たす(*2)。

 XEAD Driverで新規開発する際には、特別の事情がない限りデフォルトのDBMSであるJavaDBを使ってもらえば済む。にもかかわらず、なぜ他のDBMSでも利用できるようにしたかというと、既存DBのままで開発基盤だけを差し替えるようなプロジェクトでも活用してほしかったからだ。それだけでなく、別のDBMSに乗り換えるためにも便利なのだろう。既存DB上のデータを必要に応じて読ませながら、部分的に新規DBMSに差し替えてゆく、といった芸当もできるからだ。それぞれの事情に応じて活用してほしい。


*1.動的参照とは、参照先レコードにアクセスするために動的な手続きをともなうテーブル参照のこと。仮想フィールドが外部キーに含まれるケース、参照先テーブルのキーが有効期間のような範囲指定になっているケース、条件によって参照先テーブルが変わるケースなどがある。
*2.言うまでもないが、DBMSだけでなく開発基盤の交換容易性についても配慮が要る。詳しくは「システムの『基盤交換性』を見極める」の記事を参照。

|

« ソフト開発に資材が要らないことの優位性 | トップページ | 問題領域とコンピュータの狭間で »

コメント

できれば基板層内で改造というか、チューニングできると良いですね。
Not Existsを使うより、Not Inの方が速くなるRDBMSも有るし。
で、アプリケーション自体は、そこを気にせず論理的な操作だけをすれば良いという様にね。

投稿: いなみ | 2014.05.20 13:11

いなみさん

御意。ちょうど今、レスポンスを良くするために、ある種の読取操作のための命令をDBMS毎に切り替えるように修正を進めているところだったりします。開発基盤はDBMS毎のクセを生かしつつ吸収する役割も果たすということですね。

投稿: わたなべ | 2014.05.20 17:50

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: DBMSの交換容易性と開発基盤:

« ソフト開発に資材が要らないことの優位性 | トップページ | 問題領域とコンピュータの狭間で »