Ruby
- ActiveRecordほぼ一択
- MySQLとPostgresとSQLiteを横断して使えるし、実際にきれいに横断して使われてる
PHP
- mysql_ 関数を直でいじる長い歴史
- PDOを直で触る長い歴史
- Eloquent ORM (Laravel同梱のORM)
- CakePHP ORM
- Zend DB
Python
- Django ORM （Webフレームワークではこっちがメジャー）
- SQLAlchemy （ORM単品ではこっちがメジャー）
- そもそもデータ分析では一旦DataFrameにして列指向で集計すると行単位で操作するRDBの世界とは離れる
Java
- JDBC直書きの長い歴史（& Oracle依存のSQL使いまくり）
- Spring JDBC
- JPA
- S2JDBC(Seasar2のORM)
大事なポイントは、「言うほど一つのプロジェクトでDBMSを変えることなどない」というところ。
PHPはMySQLべったりなコードは多い。Java（というか業務系の現場）ではOracleべったりなコードは多い。
当然のことながらちょっとしたラッパーは作るから「独自ORM」というのが正確か。
べったりというと「移植性が悪い」というマイナスポイントはあるが、DBの性能を最大限に活かそうとするとそうなる。
例えば、MySQL専用で書くなら以下の機能が便利。
- limitで絞ってもヒットした全体の件数を返す機能（FOUND_ROWS）
- SQLでoffsetしなくてもseekで移動する機能
Oracleでは以下の機能が便利だったりする
- ROWIDを使った最速のキーダイレクトなアクセス
- シーケンスを使った採番
- NULLと空文字列を同一扱いできちゃう
DBMSが持つ機能をフルに活かす（もしくは意識せず使っちゃう）ことで、DBMSの依存ってのは起こりうる。
逆にRailsがかなり特殊。
- お勉強フェーズではSQLite
- 本家はPostgres
- 実際にはMySQLに繋げてる人もかなり多い
と見事にDBMSに依存せずに書いてる。
その代わりDMBS側でやってほしいことをフレームワーク側で肩代わりしてる。
- 絶対に主キーは必要（ROWIDに依存したくないから）
- デフォルトでは主キーはオートインクリメント
- デフォルトのページングはoffsetではなくidのカーソルベースでのページング
- そんな制約もあって複合主キーは認めない
- lock_versionというカラムを作っておくと勝手に楽観的ロックしてくれる
DBSMなんてただのデータ置き場だというくらいの扱い。
一方で「ORMは所詮はSQLビルダー。要らない！」という思想もある。
ORMが吐くSQLが「想像できない」からパフォーマンスが悪いSQLが吐かれていても分かりにくい。
ActiveRecordはログ出力機能ONにしておけば、すべてのSQLをきれいに表示してくれるので「想像しにくい」のは心外なのだが、開発スタイルとしてログを見る習慣が少ない人もいるのも事実。実行せずともソースだけをみるだけでどんなSQLが流れるかを想像できるほうがいいという理屈もわかる。