RORの一対一関係の理解

2217 ワード

通常のテーブル設計ではmodelが一対一の関係を導入することに論理的な問題は発見されないが、異常なテーブル設計に遭遇した場合、model層の一対一の関係をうまく処理することに注意しなければならない.
シーン:
1人のユーザーが1つの連絡先を持っている
user <--------------- 1:1---------------> contact
1対1のテーブル設計は、外部キー関係を任意のテーブルに置くことができる.
Case 1外部キー関係をcontactテーブルに置く
create_table(:users) do |t|
# cloumns
end
create_table(:contacts) do |t|
t.reference :user
end
対応モデル設定一対一関係
class User < ActiveRecord::Base
has_one :contact
end
class User < ActiveRecord::Base
belongs_to :user
# columns
end
Case 2外部キー関係をuserテーブルに置く
create_table(:users) do |t|
t.reference :contact
# columns
end
create_table(:contacts) do |t|
# columns
end
対応モデル設定一対一関係
class User < ActiveRecord::Base
belongs_to :contact
end
class User < ActiveRecord::Base
has_one :user
end
質問:
case 1とcase 2を観察すると、case 1は比較的に正常で、userを主表とし、contactをサブ表とする関係を表していることが分かった.しかし、実際には、外部キー関係をuserテーブル、すなわちcase 2に置く場合があるが、caseのmodelには、userテーブルがcontactテーブルのサブテーブルであることが反映され、論理的におかしい.
問題の分析:
これは実際にrailsのhasを反映しています.oneとbelongs_to 2つの方法のいくつかのtrickは、rubyがこの2つの関数を参照する際のいくつかの潜帰則を反映している.
  • model Aでhas_を使用one Bの場合、ターゲットテーブル(Bテーブル)にAテーブルの外部キーA_が必要となりますid
  • model Aでbelongs_を使用to Bの場合、ソーステーブル(Aテーブル)にBテーブルの外部キーが必要で、B_id

  • これも正しい、データテーブルの設計時に本来正常な論理でテーブルの外部キー関係(r)を設計していないので、RORの関数規則を守らなければならない.
    stackoverflowもこの点について話しました:http://stackoverflow.com/questions/861144/ruby-on-rails-has-one-question

    .