このような状況でいくつの列が必要ですか？

Question

これはモデルフィールドを扱う際の一般的な質問であり、これが正しい方法かどうかを知りたがっています。これは私が右10のブール列を作るために持っていることを意味

Swimming Pool 
Hot Tub 
Tennis Court 
Boat Parking 
Horse Facilities 
Balcony 
Pets Allowed 
Energy Efficient 
Lease Option 
Disability Features 

：さんは、私がモデルをHouse持っており、ユーザーはそれを持っている10個の機能の選択肢を選択することができましょうか？たくさんのテーブルの欄で働いたことがないので、わかりません。そんなに多く持っているのは普通の練習ですか？

ありがとうございます。

Answer 1

もう一つのオプションは、HouseOptions（または好きなもの）と呼ばれるテーブルと、次にUserHouseOptionsのようなものと呼ばれる結合テーブルを持つことです。

ARの関係は次のようになります。

# user.rb 
has_many :user_house_options 
has_many :house_options, :through => :user_house_options 

# user_house_options.rb 
belongs_to :user 
belongs_to :house_options 

# house_options.rb 
has_many :user_house_options 
has_many :users, :through => :user_house_options 

ユーザー、そして、余分な列がありません。それは単にARの関係を通してテーブルを結合するだけです。ユーザーハウスオプションには、user_idとhouse_options_isという2つの列があります。ハウスオプションには文字列（「プール」など）だけがあり、参考表です。これはhas_manyの詳細については、ガイドレールから

チェック：関係（およびサンプルコード）を介しは： http://guides.rubyonrails.org/association_basics.html#the-has_many-through-association

Answer 2

これは用途に応じて、たとえば次のような配列のフィールドを作成することができます。フィーチャとして知られており、その配列にハウスが持つタイプのフィーチャを挿入できます。

Answer 3

これは実現可能かもしれないが、コードを実装することは厄介である可能性があります。 一つの可能​​な解決策は、ここでは単にハッシュある好みを使用しますが、あなたはまた、配列

別のソリューションを使用する各機能のためにテーブルを作成し、使用が加入それでもthatsの可能性ができ

class User < ActiveRecord::Base 
    serialize :preferences 
end 

user = User.create(:preferences => { "background" => "black", "display" => large }) 
User.find(user.id).preferences # => { "background" => "black", "display" => large } 

をシリアル化することです面倒なヘクタール。私はこれを熟考して私の答えを更新します

Answer 4

私はフィールドの数には驚いていませんが、新しい機能を簡単に実装できるようにデザインを一般化したいと思うかもしれません。

彼はデザインのアイデアです。

> rails generate Model Feature type:string house_id:integer 

class House < ActiveRecord::Base 
    has_many :features 
end 

class Feature < ActiveRecord::Base 
    belongs_to :house 
end 

class SwimmingPool < Feature 
    def to_s 
    "Swimming Pool" 
    end 
end 

house = House.create 
house.features << SwimmingPool.new 
house.save! 

house.features.each do |feature| 
    puts feature 
end 

Answer 5

（ポリモーフィッククラスを使用して）私の他の答えはちょうど考えです。もう一つのより単純な方法は、名前フィールドにSwimming Poolをリストするfeature_typesテーブルと多対多のリンクテーブルを用意することです。 has_many：throughを参照してください。

この表のソリューションは、別のタイプを追加するために簡単に拡張できます。

多型クラスの解決法は、クラス固有の動作を拡張したい場合に拡張可能です。たとえば、スイミングプールには、フィーチャテーブルの品質データのto_sベースに「オリンピックサイズ」のようなデータが含まれている場合があります。