2

mongo_mapper を使用して、Rails で mongodb を使用して最初のアプリケーションを試しています。以下のような STI モデルでオプションを検討しています。

それは問題なく動作し、もちろん、現在数え切れないほど多くの方法でこれに追加します。埋め込みドキュメントなどを使用したほうがよいのではないかと思っています。

私は自分のモデルをできるだけ共有したいと思っています.IEはすべて特定の属性を継承しているため、property/_form.html.erbの共有フォーム部分...独自のフォーム要素などに加えて.私はビューを知っています.は異なりますが、コントローラーについてはまだわかりません。ほとんどの場合、プロパティコントローラーを使用できると思いますか? そして、私が進むにつれて、それはより複雑になると確信しています。

ポインタリソースおよび/または知恵（痛みを軽減するヒント）は大歓迎です

プロパティ.rb

class Property
      include MongoMapper::Document
      
      key :name, String, :required => true
      key :_type, String, :required => true
      key :location_id, Integer, :required => true
      key :description, String
      key :phone, String
      key :address, String
      key :url, String
      key :lat, Numeric
      key :lng, Numeric
      key :user_id, Integer, :required => true
      timestamps!
    
    end

レストラン

class Restaurant < Property
  key :cuisine_types, Array, :required => true
  
end

バー

class Bar < Property
  key :beers_on_tap, Array
  
end
4

2 に答える 2

3

より多くのモデルを恐れないでください。オブジェクト指向の考え方は、懸念事項を小さな断片に切り分け、それぞれを必要な方法で処理できるようにすることです。

たとえば、Property モデルは多くのことを行っているようです。行っている地理情報を EmbeddedDocument (緯度、経度、住所など) に分割してみませんか? そうすれば、コードはよりシンプルで読みやすくなります。

私自身もこの種の STI を使用していますが、コードがよりシンプルで使いやすくなっていることがわかりました。Mongo のような DB を使用する利点の 1 つは、このような非常に複雑な STI を実行しても、管理しやすいデータ コレクションを保持できることです。

あなたのcuisine_typesとbeers_on_tapなどに関しては、それらは素晴らしいコンセプトだと思います. 料理とビールのモデルもあると便利な場合があります。そのため、データベースはより正規化されたままになります (Mongo では失われやすい概念です)。例えば：

class Bar < Property
  key :beer_ids, Array
  many :beers, :in => :beer_ids
end
class Beer
  include MongoMapper:Document
  key :name, String
end
于 2010-02-15T17:41:38.510 に答える
0

同じクエリでレストランとバーの両方を返すことを期待していますか？

そうでない場合は、基本タイプから派生させることを再検討することをお勧めします。

デフォルトでは、Mongo_Mapperはレストランとバーの両方を1つのコレクションに入れます。これにより、パフォーマンスが低下し、将来的に拡張が困難になる可能性があります。

Mongo_Mapperコードのいくつかを見ると、set_collection_nameを使用してその場でこれを設定できる可能性があるようです。

于 2010-02-23T21:58:28.323 に答える