アプリケーションとDBの分離による変更コスト
私は、
- プログラムを理解するのに必要なことはソース中に書け(コンパイラのチェックも通るし)。中でも重要なことはできるだけ一箇所に集中して書け。
- よって、コメントは最後の武器だ。
- ましてプログラムをドキュメントで説明するのは敗北宣言だ。
- よって、データ型やテーブル定義を見れば、プログラム全体が理解できるようにすべきだ。
- 型なし言語逝ってよし。
ぐらいに思っている人間なので、これには賛成しかねます。
http://d.hatena.ne.jp/kmaebashi/20090430/p1
正しく伝わっていないので補足します。上記の5点は激しく同意です。オブジェクト指向分析の一歩がインスタンスの抽出であるように、ソースコードの解析もデータ構造の把握から始めるのが一番だと思っています。
RDBの一番の問題は、アプリケーションとDBの両者でデータ構造を定義していて変更コストが高いところじゃないかなぁ。アプリケーションコードとSQLが分離されているのでリファクタリングも手間がかかります*1。さらにSQL文自体の変更コストが高い。
お客様の属性項目を1つ増やすだけで、エンティティやらデータアクセスやらSQL文やらテーブル定義やらを変更して、それぞれの影響範囲を確認しているのは無駄な気がします。最初に決めたデータ構造を変更するコストが高すぎます。
私がここまで変更コストにこだわっているのは、変化に対応できないアプリケーションに未来はないからです。5年毎に作り直す情報システムは今後もなくならないでしょうが、変化に追従できる情報システムはより重要になってくるでしょう。
なるほど、個々のダイアリを表示するのであればこれは優れた方法です。RDBMSのモデルだと、誰かの日記のある日の1エントリを表示するために、全エントリを含むテーブルから検索しなければなりません。どのダイアリを表示するかわかっている局面なら、オブジェクト指向なモデルの方がよさそうです。
……で、はてなダイアリトップページのホットエントリを表示しようとした時点で、全エントリを縦断検索できる方法がないことに気付いてはまることになりそうな。
http://d.hatena.ne.jp/kmaebashi/20090430/p1
上記はオブジェクト指向モデルの一面しか捉えていないように思います。もしSQLに "JOIN" がなければ同じことが言えます。コレクションから1オブジェクトを取り出す操作だけでなく、1対多の関係を展開する操作を付け加えればいいだけです。
あれ？それってSQLの再発明じゃない？
正解です。問題の本質は、アプリケーションからシームレスにデータモデルにアクセスできないこと。アプリケーションのネイティブ言語でデータモデル（集合）を読み書きできるようになれば、変更コストの問題は解決できると思います。クラス定義とテーブル定義の二重定義もなくなりますね。
