トラックバックとブックマークコメントへのお返事です。
SQLについて
id:hatest さん
タイトルのとおりです。
言語としてみたときのSQLは、BNFからしてこのありさまなわけでなんというかもう。前にも書いたように私はSQLが苦手なのですが、そこそこ得意な人でも、サンプル見ながらじゃないと書けないケースは多いんじゃないでしょうか。
http://savage.net.au/SQL/sql-2003-2.bnf.html
以前、「言語の萌え度」というのを考えましたが、これでいくとSQLはCOBOLと並んで萌えない言語のように思います(まあそう考えればWeb界隈で言及が少ないのも当然だわなあ)。
key-value DBについて
id:niam さん
J2EE全否定疑惑。でも、基本的には同意。Transaction処理がcriticalに必要な部分(金銭処理)以外はもう、RDBもいらなくて、Key Value Storeでいいんじゃないでしょうか。Tokyo Cabinetとかmemcacheとか使える人を雇えば・・・
id:int128 さん
現実は現実でいいんだけど、RDBの制約がAPに波及しているのが悪い。RDBがkey-value DBになれば設計も変わるだろう。
J2EEというかEJBは存在自体が間違っていたということでFAだと思うんですが。
それはさておきkey-value DBですが、正直「memchachedくらいは聞いたことはある」程度だったので調べたんですが、はてなとかでも部分的には使っているとはいえ、これでアプリケーション全体が作れるとは私には思えませんでした。
id:int128さんにはトラックバックもいただいていますが、
http://d.hatena.ne.jp/int128/20090428/1240892134
Key-Value形式はオブジェクトが属性を持つという性質に合っているし、オブジェクトとオブジェクトが関連を持つことも表現可能です。継承が使えないのはまったく問題ではないし、厳密な型定義はアプリケーションでチェックすべきです。
私は、
- プログラムを理解するのに必要なことはソース中に書け(コンパイラのチェックも通るし)。中でも重要なことはできるだけ一箇所に集中して書け。
- よって、コメントは最後の武器だ。
- ましてプログラムをドキュメントで説明するのは敗北宣言だ。
- よって、データ型やテーブル定義を見れば、プログラム全体が理解できるようにすべきだ。
- 型なし言語逝ってよし。
ぐらいに思っている人間なので、これには賛成しかねます。
なんらかの業務アプリケーションの開発現場に、新たな要員が投入されたとき、まずテーブル定義からアプリケーションを理解してもらう、というのは普通に行われているんじゃないでしょうか。
できることなら、オブジェクト指向で作るほうがよいのか
「使わない」んじゃなくて、「使えない」が大半じゃないだろうか?SQLができる云々はごもっとも。だけどOOPがちゃんと使えれば、(設計次第だけど・・・)メリットのほうがでかいと思いまふ。
これなんですが。
たとえば、JavaなりC#なりのオブジェクトを透過的にストレージに保存できて、トランザクション処理もできるオブジェクト指向データベース(OODB)があるとしましょう(ていうかそういう触れ込みの商品は過去いくつもあったはずで)。
で、それを使って、前回のサンプルどおり、はてなダイアリを作るとします。
前回、こんなことを書きました。
- 1「ユーザ」に対し、n「アカウント」(サブアカウントとやらがあるらしいので)
- 1「アカウント」に対し、1「ダイアリ」
- 1「ダイアリ」に対し、n「日記記事」(「日記記事」は1日分の記事を表現する)
- 1「日記記事」に対し、n「エントリ」
これをRDBMSで作るとすれば、記事本体は「日記記事」テーブルに保持され、かつ、「エントリ」テーブルがその中の個々のエントリを管理することになるでしょう。
ではこれをER図でなくUMLで書いて、オブジェクト指向言語のクラスにマッピングするとどうなるかというと、自然に設計すれば、「ダイアリ」クラスが複数の「日記記事」クラスを配列等のコレクションで保持し、かつ、「日記記事」が複数の「エントリ」を保持する形になるんじゃないでしょうか。
なるほど、個々のダイアリを表示するのであればこれは優れた方法です。RDBMSのモデルだと、誰かの日記のある日の1エントリを表示するために、全エントリを含むテーブルから検索しなければなりません。どのダイアリを表示するかわかっている局面なら、オブジェクト指向なモデルの方がよさそうです。
……で、はてなダイアリトップページのホットエントリを表示しようとした時点で、全エントリを縦断検索できる方法がないことに気付いてはまることになりそうな。
オブジェクト指向設計において、実行時のデータ構造はたいていツリーなりグラフなりになっています。これは、ある見方において、現実世界なり業務なりを直接表現しているのかもしれませんが、実はその見方に対し「早すぎる最適化」をしてしまっているのかもしれない。業務アプリケーションにおいて機能の追加は日常茶飯事ですが、RDBMSだと泥臭くてもたいていなんとかなるところ、下手にOODBに乗せるとどうしようもなくなるケースが多いように思います。
RDBMSは、モデルを表現するスキーマとしてそこそこに強く、アドホックに機能を増やす拡張性においてもそこそこに強い、という点において、なかなか良いスタンスを取っていたからここまで普及したのかな、と思います。
インデックスさえちゃんと効くのであれば、誰かの日記を表示するのに全エントリ検索したところで、負荷は指数関数的に減る…はずですし。
その他
id:terazzo さん
ロジックのみ書けば良いというのはアーキティクチャとして完成形に近いのだろう。/SQL書けば完了系のシステムだと、権限の扱いとかはどうしてるんだろう。
前段は、
http://ameblo.jp/argv/entry-10064288690.html
「業務ロジック」というのは、ユーザーの業務に特化した処理である。そのため、それぞれのシステムによって処理内容が違い、その都度新しく処理を「書く」必要がある。一方、業務ロジック以外の部分は、どのシステムでも似たようなものになりがちなので、ある程度は汎用的な仕組みでの対応が可能だ。システム開発の効率化を考えるとき、業務ロジック以外の部分の汎用性を高めて「書く量」を減らすというのは重要なことである。そういう意味で、「業務ロジックしか書きたくない」というのは自然な話である。
という話ですよね。
後半ですが、別に「SQLだけ書けばすべて完了」のシステムなんて存在しないわけで、権限のチェックはどこかで行います。「部長以上でなければ見てはいけない画面」なら、カスタムタグなり何なりでセッションに保持しているロールをチェックして、権限がないなら表示しない、という処理をするのではないでしょうか。見るのはよいけど更新はだめ、という場合はビジネスロジックで判定が必要そうです。いずれにしても、ログインIDからロールを抽出しセッションにセットするところまではフレームワークの仕事かと思います。