SQLに依存することの危険性 ー 単体DBサーバでは終わらない時代の考え方 | 独り言v6
ベンチャー社長で技術者で:ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！. というのを目にした。要するに「OO言語＋RDBな組み合わせ」において、O\Rマッピングに頼らずにちゃんとSQLとストアドを書いた方がいい、と言うことである。 L.staｒは元々Java屋でそれからSQLに移ったので、未だに自分が両方をバックグラウンドに持つ人間だと思っている。O/Rマッピングのイ ンピーダンスミスマッチを解決する簡単な方法が実は無い、と言うぐらいには両方を理解している。だからこそ言いたいが、この文章、特定のDBが中央に鎮座していて、それがすべての中心になるような業務システムにおいては完全に正しい。ただし、元々そう言うシステムを念頭に置いて書かれた文章であるので、その点はちゃんと考えるべきだ。O/Rマッピングに頼り切って、SQLをきっちり書かない、ということをすると性能が出
ORMがアンチパターンである11の理由
サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。 I cannot overstate the degree to which ORM is a dangerous antipattern. — Laurie Voss (@seldo) June 9, 2011 ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。 当初は有益
DoctrineでSQLを直接実行する - ゆっくり*ゆっくり
ORMの構文を必ず使う必要なんてないのですよ。 <?php // なんでもいいのでConnectionとってくる $employeeTable = Doctrine_Core::getTable('Employee'); $con = $employeeTable->getConnection(); $sql = "SELECT * FROM employee where YEAR(employed_at) = :year"; $employees = $con->fetchAll($sql, array(':year' => 2009)); $sql = "SELECT * FROM employee ORDER BY employed_at DESC LIMIT 1"; $employee = $con->fetchRow($sql); $sql = "SELECT id FROM e
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
