Ormマッパーについて

SQLをガリガリ書く必要がないから、
Ormマッパが使われているのだろうが、

1. 標準SQLさえロクにサポートしていない
2. 分析関数を使えない。
3. WITH区を使えない
4. ストアドプロシージャが使えない
5. VIEW(CREATE VIEWで使うデータベース側のもの)が使えない
6. プログラミング言語ごと、ライブラリごとに表記が違うため、結局のところ、SQLを覚えるより学習コストが高い。また、プログラミング言語、ライブラリが変わるとコピペで動かない。

などかなり馬鹿にできない欠点がある。

このような欠点が生まれた理由は、

「データベース側のテーブル１つが、プログラミング言語側のオブジェクト１つに対応しているという前提でORMマッパは設計されている」

からであると思う。
なので、データベース側でJOINするようなSQLを書くのは難しいし、場合によってはかけなかったりする。

このため、非常に効率の悪いSQLを書く必要があったり、
TABLEの中にメモ１、メモ２、メモ３といった
カラムを作成する人が現れる。
（これだと、TABLEが集合である意味がない）

これらのORMマッパの欠点は、技術的な問題でなく、上の前提自体が間違っているためである。
なので、これからも欠点は解消されるとは思えないし、
生のSQLを使うようになったら、全て解消される欠点なので、いずれORMマッパは
使われなくなると思う。

ORMマッパは下のような会社にだけ使われるようになると思う。

1. データベースに詳しい人が少ない会社で、時間とお金がない
2. 単に仕事に必要なことを勉強する気がない

1の場合はある程度仕方ないが（データベースエンジニア、SIは除く）、
2の会社はいずれ潰れる。


散々、Ormマッパの悪口を書いたが、
RAILSのライブラリなどはオームマッパを使うこと前提の設計になっている
ため、効率が悪いSQLを作成することがわかっていても、
ORMマッパを使うことを止めづらい。
また、今は、オープンソースのライブラリを見ても
ORMマッパを使いっているものが多いので、
使わない場合は、
0からスクラッチする必要が出る。
このため、他社と比べて開発速度が落ちる可能性がある。
（私としては、テーブルを自分で０から設計できる能力があるなら、データベースの部分は０からスクラッチしてもそんなに遅くならないと思うが。運用のことまで考えるとこちらの方がお金がかからない可能性もある。）


また、ネットでも生のSQLを使って書いたSQLが少なく、
「JOIN、IN,EXISTS,GROUP BY, HAVING」がわかっていない
人が記事を書いている場合が非常に多いので、
本当にこのSQLで良いのか、わからない人も多いだろう。

このブログの方針としては、
現在プログラミング言語、フレームワークから
ORMマッパで書くことが多い部分は、
生のSQLを書き、
「ORMマッパならどう書くか」と合わせて説明していく。