既存のテーブルをRailsで使う場合の鬼門は ・テーブル名称が'Rails-Aware'ではない(複数形を使っているとは限らない) ・プライマリキーの名称(列名)が'Rails-Aware'ではない(idという名前ではなく、コード設計上で一意とされている名称が使われる) 本来はRailsに合わせるべきなんだろうが、Railsのためだけにスキーマを修正してくれ、なんて、気むずかしいDBAに言おうものなら半××ものだろう。 従って、レガシ(あえてこう呼ぶ)なテーブルはRails側で流儀を合わせる必要がある。以下、その手順 これもいろいろな所で散々既出なので、詳しくは解説しない。備忘録としてメモ。(既にRailsコマンドでプロジェクトが生成されており、データベースにも接続可能になっていることとする) 1. 既存のスキーマを元にモデルを生成する どうせモデル名とテーブル名は合わないので、好きな名称
● [熊井ちゃん][Rails] テーブル設計 熊井ちゃん、DQMJのモンスターの生息エリアってどう管理してる？ 「モンスター」と「エリア」をエンティティ(リソース)と見做せば、関係テーブルが必要になるのはいいとして、これは運用上変更されない静的な関係だから、このテーブルにIDを導入する必要性は感じないよね。 てことで、テーブルはこんな感じになるんだけど、これって Rails でどう表現すればいいの？n:mなら habtm がピッタリだけど、生息エリアが1箇所のみ(n:1)とすると、 やっぱり habto が欲しいよね。実装はどうしよう？またあの地獄の ActiveRecord::Associations に頑張って追加するの？1.1 と 1.2 で結構違ってるし、そんな体力はないよ。
Rails 1.1以降のActiveRecordではhas_and_belongs_to_manyの代わりに has_many :through を使うのがトレンド。これはこれで便利なのだけれど、Activity Based Datamodel式のテーブル構造を使うためにはやっぱりhas_one :throughも欲しい。 本家のMLでは7月24日の"belongs_to :through?"とかいうスレッドでdelegate使えとか言われてる。でも、その場合発行されるSQLが効率悪そうで嫌だ。やっぱり結合して一気に持って来たい。 で、作ってみた。プラグインでも、environments.rbに直接書き込みでも好きなようにインストールしてください。暫定版だし。 ActiveRecord本体の関連の実装に激しく依存してるというたちの悪さ ActiveRecord 1.14.3で動作確認。他は
DHH 本がきたので、ちゃんと入門するよ！ ところで全然どうでもいいけど、本を読むと本のマジックというかなんというか、読んでいる間は「うわすげぇー簡単じゃーん」とかわかった気になるんだけど、実際のケース (今作ろうとしているのも) に当てはめようとするとことごとくうまく行かないという泣きたくなる情況が頻発して凹む。 とりあえず多対多の場合 ActiveRecords は id カラムを持たないテーブルを一個仲介役に作ってあげるみたい。んでテーブル名は二つのテーブルをアンダースコアでつなげたものにするらしい。(244 ページ, has_and_belongs_to_many) それで、一個疑問は解けたけど、実際にやってみようとすると問題がまたでてくる。例えば vote っていうのはそれぞれの Topic に対して User がそれぞれ投票できるような感じ (Topic と User が多対多
● 中途半端な ActiveRecord#find_all ORM(O/Rマッピング)が一番効果を発揮するのは「単一レコードに対する単純な CRUD 操作」であろう。DBのレコード1行と1オブジェクトを1:1の関係で捉えることによる明瞭な関連性と、その関連が主キーにのみ依存するという疎結合を同時に実現しているからだ。複数エントリに対する操作の場合、前者の関係性は同じくn:nで明瞭であるが、後者の関連に関する記述(条件節等)が問題になってくる。例えば、テーブルの全エントリを取得するような場合は問題ないが、条件や件数指定や結合などにより複雑なクエリになった場合、そのクエリをどうモデル化するかという問題が発生する。ARでは参照クエリの実行を find_xxx 系のメソッドで提供しており、例えば find_all では先程の条件指定をこのようにモデル化している。 # activerecord/li
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
