id:int128さんから再度トラックバックをいただきました。
「アプリケーションとDBの分離による変更コスト」
http://d.hatena.ne.jp/int128/20090430/1241112977
う。どうも余計なことを書きすぎたようで。
- プログラムを理解するのに必要なことはソース中に書け(コンパイラのチェックも通るし)。中でも重要なことはできるだけ一箇所に集中して書け。
- よって、コメントは最後の武器だ。
- ましてプログラムをドキュメントで説明するのは敗北宣言だ。
- よって、データ型やテーブル定義を見れば、プログラム全体が理解できるようにすべきだ。
- 型なし言語逝ってよし。
この5点のうち、この文脈で重要なのは最初のひとつだけでしたね。
key-value型のD/Bのような、ある意味いいかげんなD/Bにデータを突っ込み、その解釈をアプリケーションで行うとすると、RDBMSならテーブル定義に相当するようなものがアプリケーション全体に分散してしまうのではないか、というのが先の発言の趣旨でした。
RDBの一番の問題は、アプリケーションとDBの両者でデータ構造を定義していて変更コストが高いところじゃないかなぁ。
これはわかります。現状、そういう形で作られているシステムが多いでしょう。
で、int128さんの考える解決の方法は、「D/B側はkey-value型のようなゆるいスキーマにしておいて、実際のデータ構造の定義はアプリケーション側だけで持つべきではないか」ということなのだと解釈してます(間違っていたらご指摘ください)。
でも、ひとつのデータベースに対し複数のアプリケーションがアクセスするのはよくあることなので(ていうかそれが本来のデータベースの定義なので)、それは逆なんじゃないでしょうか。つまりデータ構造の正しい定義はむしろ「D/B側だけで」持つべきではないかと。
お客様の属性項目を1つ増やすだけで、エンティティやらデータアクセスやらSQL文やらテーブル定義やらを変更して、それぞれの影響範囲を確認しているのは無駄な気がします。最初に決めたデータ構造を変更するコストが高すぎます。
ActiveRecordというか、テーブルひとつにクラスを対応させるようなクラスは実際よく見ますけど、いざ業務アプリを書いてみると、テーブルの全列を取得しなければならないことなんてまずなく(「SELECT *」は禁止とかね)JOINはあって当たり前でJOIN対象のテーブルもばらばら、ということが多くて、あまり使えない気がしています。もうこんなことならJavaのResultSetやASP.NETの型なしデータセットでもいいんじゃないかと最近思っていたり。「型なし言語逝ってよし」とは思い切り矛盾しますけど、それが嫌ならアプリの機能ごとにクラスを起こしてもいいんじゃないでしょうか。
だとすれば、お客様の属性項目ひとつ増やした時は、関連する部分以外は直さずに済みます。
上記はオブジェクト指向モデルの一面しか捉えていないように思います。もしSQLに "JOIN" がなければ同じことが言えます。
ここはよくわかりませんでした。
私が書いているのは、普通にクラス設計すると「エントリ」を日記ごとに分けて持つことになりそうだけど、別の機能では、全日記を縦断して検索しなければいけないこともある。そういうことを考えるとRDBMSは、データ構造定義の「強さ」と「ゆるさ」において、業務アプリ向けにはなかなかいいところでバランスしているのではないか、ということです。
もひとつ。
「Re:業務アプリの業務部分で、オブジェクト指向なんか使わないよね」
http://d.hatena.ne.jp/fumokmm/20090501/1241181093
だがしかし、だからといってオブジェクト指向が要らないというのは少々飛躍しすぎな気がしてならない。オブジェクト指向の利点であるカプセル化やポリモーフィズム、そして継承などの有益な機能は利用できなくなる。それにオブジェクト指向はアルゴリズムをシンプルにする力を持っていると思う。見なくていい部分は内部に隠されている。
いやだから具体例でお願いします。私ははてなダイアリーを例にしましたけど、同じ例でも他の例でもいいですから。
ある具体的なアプリケーションにおいて、どうクラスを抽出し、どうカプセル化やポリモーフィズムや継承を利用するのか、この手の話は具体例で議論しなければまったく意味がありません。
私の考えるエキスパートとは、どちらか一方のみではなく、互いの欠点と利点を理解した上で利点のみを組み合わせて使うことができる人材である。ボトルネックとなる部分は高速なSQLを魔法のように操り、万人が理解できるよう、十分に考え抜かれたインタフェースを業務アプリのビジネスロジック部分のコードに提供する。そんな設計・実装ができる人材だと私は思う。
ここはまったく同意します(うまくやりたかったらうまくやれ、的なアドバイスと変わらないような気もしますが)。
「互いの欠点と利点を理解した上で利点のみを組み合わせて使」おうとすると、業務アプリの業務ロジック部分にオブジェクト指向の出番なんてほとんどないよね、というのが私が先のエントリで書いたことです。
