SQLとオブジェクト指向、O/R マッピングの話
ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！ http://t.co/sVHcOtedfo -- これと、
— 増田 智明 (@moonmile) 2013, 9月 20SQLに依存することの危険性 ー 単体DBサーバでは終わらない時代の考え方 http://t.co/fxEe4Dxndo -- これを、後で読む。
— 増田 智明 (@moonmile) 2013, 9月 20読んで、なんか書こうと思ってそのままに。
ざっと箇条書きをしておこう。
- ストアドプロシージャは、変数とか制御文とか使わないと意味がない。
- クエリにストアドプロシージャを入れると、パフォーマンスが悪くなる。
- 今だと、SQLの解析は全然問題にならない。なので、プリコンパイルの速度的な意味はない。
- O/R マッピングのインピーダンスミスマッチについては、ミスマッチが発生する前提でプログラムを書くのが正しくて、逆に言えば「ミスマッチがない」という前提が間違い。
- なので、作業量やプログラマのスキルを見込んで、言語と方法を分ければOK。前提条件と適用範囲があるので、どの組み合わせが良いとは限らない。
- が、SQL を知らずに、O/R マッピングだけ使うのは危険かな、と思うのだが、これは単なる老婆心かもしれない。最初から、WEB サービスとして CRUD が用意されていれば、SQL 文関係なくプログラムを書くだろうし、それは DB とそれを利用する人の距離にある。
- Google などの検索機能だって、いまだと普通の人が使っているけど、10年前は、検索自体はコンピュータの専門家がやる（資格を持った人がやる）という意見もあった。かつて、DB は高価だったのだ（Oracle や DB2 など）が、今では MySQL を初めとしてフリーあるいは安価に使えるようになっている。この、利用の広まりとコストダウンも、O/R マッピングとオブジェクト指向との問題にもかかわってくる。
結論から言えば、状況にあわせて、ってことなんだが「どうやって、状況にあわせて選ぶのか？」の選択理由（あるいは根拠）が必要だよね、と思っている。記事を書くときにはそれを注意して > 自分。
