O/R Mapper についてかんがえてみた
元ネタ）http://d.hatena.ne.jp/tokuhirom/20110104/1294170319 昔良くORMを使うことのメリットは SQLを書かなくてよくなる。 つまりプログラマはSQL脳が低いからプログラマにSQLを書かせない。 プログラム中にSQLという別の概念がはいってくるとコードが読み難くなる。 バックエンドのRDBMSの差異を吸収してくれるからバックエンドを気にする必要がない。 さらに、バックエンドのRDBMSを簡単に取替え可能。 プログラマブルにSQLを組み立てしたい。 などと言われることが多いんじゃないでしょうかね。 個人的には最後の「プログラマブルにSQLを組み立てしたい」と言う要件以外は全部 間違っていると思います。 イカ全て自分の視点なだけなので違う意見もあるであろうことを承知で言い切ります。 SQLを書かなくてよくなる。つまりプログラマはSQL脳が低い
MySQLで多段slave
いまデータベースサーバを物理的に交換する必要が発生してしまい メンテナンス準備をしています。 現在の構成としては db1.local(master) db2.local(slave) という構成なのですが、なるべくダウンタイムを短くしたいのが世の常でしょう。 そこで稼働中のサーバを止めずに準備をします。 目指す最終型はこんなの db1.local(master) db2.local(db1.localのslave) db3.local(db1.localのslave & master) db4.local(db3.localのslave) こんな構成にしておけば一瞬メンテナンス画面にして、DBへのアクセスを遮断 db3.localのslaveがmasterに追いついた時点でアプリケーションのDB接続先をdb3.localにして 運用という形にできるかなと。 メンテ中にファイルコピーとか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
