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

不要害怕更多的模型，OO 的想法是能够将您的关注点切成小块，然后以需要处理的方式对待它们中的每一个。

例如，您的 Property 模型似乎做了很多工作。为什么不将您正在处理的地理信息拆分为 EmbeddedDocument（lat、lng、地址等）？这样您的代码将保持更简单和更具可读性。

我自己使用这种 STI，我发现它使我的代码更简单、更有用。使用像 Mongo 这样的数据库的好处之一是您可以像这样执行非常复杂的 STI，并且仍然拥有可管理的数据集合。

关于您的美食类型和 beers_on_tap 等，我认为这些都是很好的概念。拥有 Cuisine 和 Beer 模型也可能很有用，因此您的数据库仍然更加规范化（这个概念在 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 会将餐厅和酒吧放在一个集合中。这可能会影响性能并使未来更难扩展。

查看一些 Mongo_Mapper 代码，看起来您可以使用 set_collection_name 即时设置它。

于 2010-02-23T21:58:28.323 回答