眠る開発屋blog

RDBが扱いづらい問題はO/Rマッパーで解決できる？

思考ログということで過程の文章なのでしょうが。

スキーマを事前に定義しておかないといけない

運用中の案件においては、これはあまり意識したことがないなぁ。
確かにオブジェクトに比較するとスキーマ定義は柔軟性に欠けるのかもしれませんが、
平気でフィールドを追加したり減らしたりということをしている。
あとフィールドはなるべく緩く作るようにしている。
MySQLで言えば、単に蓄積させておくデータについては、特に長さ等は指定しない。
型はtextかintを使うことが殆どで、検索対象となるものだけ若干考える。

データ型として配列が使えない

そもそも RDB というものが複数の表を取り扱うデータ形式だからだろう。
おそらく配列型の値を扱おうとしたら、通常、正規化して別テーブルにするのが正解ってことだろうし、
単なる永続化であれば、配列ではなく、オブジェクトとしてなんでも入る方法を選択すると思うので、

この場合、一般的にはシリアル化（serialize関数）して文字列として処理→DBから取り出した後に復元（unserialize関数）（PC用語で言うと圧縮、解凍みたいなものですね、サイズは変わりませんが）という方法が採られているようですが、

ということになると思う。

プログラミング言語との連携が弱い

SQLを扱っている次点でDSLだからね。そりゃそうだ。

O/Rマッパーについて、

あと、最初にデータベース定義が必要なところはどうも解決してないっぽいですね。

ダック・タイピングというか型なし言語というか、
「実際にそのフィールドが必要となるまで、そのフィールドは定義されていたり明示化されていなくてもよい」
ということだろうか。
memcached とかグローバルなハッシュ配列という認識なんだけど、
それに表の概念と永続化の概念をぶち込めばそれっぽいのができるのか？
或いは、既存のRDBであっても、ラッパー被せてそれっぽいのを作ればよさそう。

初心者にとって、プログラム言語とSQL言語のバイリンガルにならざるを得ない状況があって、それがプログラミングの壁を厚くしているような感じがします。

SQLの学習コストって、
各種フレームワークのORマッパー操作を学ぶことに比較すればそれ程高くない気はするんだけども。
とりあえず、概要と主要な４つ・・・SELECT、INSERT、UPDATE、DELETEの使い方を覚えればいいかな。
そうであれば、２日（１６時間）ぐらいあれば学習できるだろう。
教える人間のコストを加えたとしても、
前準備（１６時間）と実際の講義（１６時間）を追加しても、結局 6日(48時間）ぐらいで済むのではないか。
新入社員研修で考えれば、それ程時間を要するとも思えない。

更に言えば、
ORマッパーの仕組みについては、
多くの言語やフレームワークで共通したスタンダードなものが残念ながらまだ出現していない状態であるのに対し、
SQLは確かにDBごとの方言はあるにしろ、ほぼ統一された仕様である。
現行の技術に対する大規模なり小規模なりのパラダイムシフトが起こったとしても、
生き残る可能性は非常に高いし、学習に対する費用対効果は比較的高いと思う。

Webプログラム以前でもMSAccessやVisualBasicなどでORマッパー的な概念はあったのだが、
結局それらの仕様が変化し発展していったというよりは、
必要に応じつつ言語特性に合わせた形で出てきた気がするし、
プログラム言語のスコープで扱われる以上、都度新しいやりかたを覚えるのは致し方ないのかもしれない。
であれば、どこまで学習するか？というのはやや微妙。

専門職としてプログラマを設定するのであれば、
SQLはやはりどこかで時間などを投資して覚えておくべき技術だろう。
専門職でないならば、そもそもフレームワークを覚えようってところが「アレ？」な気がするし、
プログラム以外に学習すべきことも沢山あるだろうしそこに学習時間を投資したほうがいいんじゃねーの、とか、
「プログラマじゃないけどプログラムしなくてはならないんですよ」という状況であれば、
「専門職をスポットで雇えばいいんじゃないの？」とは思う。

だいぶ元のエントリの本題とはずれてしまったなぁ。。。
それでも ORマッパーを便利だからどんどん使おうよ！と思うのは、
個人的には、デバッグのしやすさというか、言語スコープで問題点を見つけることができるからかなぁ。