« BOMプロセッサの開発完了 | トップページ | システム開発のHowToではなくWhatを »

2013.01.25

SQLを使わないでシステム開発

 私はSQLが苦手である。ちょっとややこしいSQL文になると調べないと書けない。入り組んだ文を一瞬で書けてしまう技術者はカッコイイと思うが、うらやましくはない。なぜならそういうものを書く必要が今までなかったし、これからもなさそうだからだ。

 このような独特な見方をするようになったのは、私がAS/400で育ったことと関係ありそうだ。独自のプログラミング言語にレコード操作コマンドが組み込まれていて、SQLを使わずに端正にRDB処理を記述できる。SQLを書かないわけではないが、データ移行やテストのときにちょこっと使う程度。そういうわけで、SQLは便利ではあったが、複雑な文まで書けるようになる必要がなかった。

 RDBの基本的な特徴として「SQLでデータ操作できる」と説明されることがあるが、私に言わせれば的外れである。RDBの本質は、帳簿組織をそのままの形で電子化できる点、すなわち表形式データをその論理構造のままで格納できる点にある。SQLは、異種のRDBMSを操作するための共通規格としては決定的に重要ではあるが、それでもRDBの利用において本質的な要素ではない。

 むしろ、RDBを核に据えたシステムの開発に特化した基盤であるなら、利用される言語の体系に文脈化されたテーブル操作手段を提供すべきだ(共通規格であるSQLをラップすれば難しいことではない)。なぜなら、ひとつのシステム定義に含まれる言語体系は、3個よりも2個、2個よりも1個のほうがいいからだ。SQLを使わないシステム開発から始めた技術者として、この思いは三つ子の魂のように変わりそうにない。

 そんなこだわりを持つ技術者が開発基盤を作ったらどうなるか。拙作の開発用プラットフォーム(XEAD Driver)は、SQLもアプリのコードも書く必要のない超高速開発ツールとして完成した。ただしアプリのコードが「自動生成」されるのではなく、専用のエディタを用いてまとめられた「仕様書」を翻訳エンジンが読み込んで、アプリをその場で立ち上げるとういものだ。

 何のためか。コーディングやユニットテストの手間をカットすることで、業務システムの開発者に「本来の専門性」を発揮してもらうためだ。すなわち、帳簿組織やビジネスプロセスの合理化に専心してもらうためだ。それだけでも十分に専門的なので、それ以外の実装上の考慮事項は少なく済めば済むほどよい。けっきょく私にとってSQLは、その種の「減らしたい実装上の考慮事項」のひとつなのである。

 開発環境には、実装作業を合理化するという明確な意志にもとづく方向性が必要だ。これが十分でないと、環境の利用者(つまりシステム開発者)にシステム設計能力が身につかない。開発を3年経験してまだ上流系スキルが深まっていないと思えるのであれば、利用している基盤や手法に問題がある。実装やプロセス論レベルの区々たる考慮を要求するばかりで「本来の専門性」を深める契機をもたらさない。そんな開発環境は技術者の時間を奪ってゆくクワセモノだ。

 XEAD Driverにおいて、いわゆる「ビジネスルール」系のロジックについてはRhino/JavaScriptで記述される。参考までに、この基盤上で開発中の生産管理システムにおける「階層部品展開」のロジックを示そう。フィーチャ・オプションでマスキングされた部品表の展開処理も、SQLを使わずに書ける(*1)。展開結果は配列(kouseiArray)に保管され、後続処理で利用される。変数定義などのこまごました部分は省略してあるが、おおまかな動きはわかるだろう。こんな調子で私は今も昔も「NoSQL」なのであった。

20130125

*1.スクリプト中のcreateTableOperatorは、基盤が提供するテーブル操作用関数(TableOperator)を得るためのメソッドで、この関数が基盤内部でのSQL文生成やDB接続といった処理を担っている。この関数にSQL文を直接渡して実行させることも可能だが、それをせずにテーブル操作をわかりやすく記述するために使うのが本来の役割である。

|

« BOMプロセッサの開発完了 | トップページ | システム開発のHowToではなくWhatを »

コメント

NoSQLに吹きました( ´艸`)

投稿: ret315 | 2013.02.22 22:19

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: SQLを使わないでシステム開発:

« BOMプロセッサの開発完了 | トップページ | システム開発のHowToではなくWhatを »