3

Productsを表示するアプリに取り組んでいます。各製品は、名前、ブランドなどのいくつかの共通情報を持つモデル (製品) です。見ている製品の種類を区別するために、基本的に tinyint フィールドであるproduct_type (電話、テレビ、ソファなど) があります (例: 1 = 電話、2 = テレビ)。

ここで、product_type に応じて、各製品は異なるオプションを持つことができます。電話の場合、製品には追加情報が関連付けられている必要があります (重量、LTE があるか、前面カメラがあるかなど)、テレビには次のような情報が必要です。表示サイズなど。

私の質問は次のとおりです。製品のタイプに応じて、この追加データを製品に追加するための最良/または/最も簡単な方法は何ですか?

追加のフィールドを格納するフィールド product_id、option_type、option_value (VARCHAR) を持つ追加のモデルProductOptionsを持つことを考えていましたが、これがパフォーマンスと検索のオプションであるかどうかはわかりません。po = ProductOption.where(:option_type => "LTE", :option_value => "yes")この場合、検索とは、特定の基準 (例: ) に一致するすべての ProductOptions をProduct.findAllIn(po)見つけてから、実際の製品を見つけるために を実行することを意味します。

または、Postgres を使用して HStore を使用する必要がありますか? HStore は検索時に効率的ですか?

何か案は？

Rails初心者、すべてのコードは疑似コードです

4

1 に答える 1

2

既に ProductType を見ている場合は、この単一テーブル継承を作成して、実際に異なる製品タイプを定義することができます。とにかくコーディングが簡単です。この場合：

class Product < ActiveRecord::Base
  # common functionality goes here
end

class Sofa < Product
  # sofa specific functionality goes here
end

次に、すべてのオプションを製品テーブルに配置できますが、製品タイプごとに異なる attr_accessible、検証、およびビューを使用できます。

このセットアップの最も優れた点は、Rails で「そのまま動作」することですtype。製品テーブルに列を配置するだけです。また、次のようにすべてのソファを見つけることができます。

Sofa.all

そしてすべてがそうです

Product.all

データベースのパフォーマンスに関しては、かなりの数の null フィールドが発生することになりますが、すべての属性は (シリアル化とは異なり) 検索可能であり、1 つのテーブルに対してクエリを実行するだけで済みます。したがって、これは私が知っている他のどのオプションよりも優れていると期待しています。

さらに、それは素晴らしく、オブジェクト指向です。:)

Railsへようこそ！

于 2012-11-12T15:40:22.303 に答える