mongodb数据设计问题

Question

我正在使用 mongo_mapper 尝试在 Rails 上使用 mongodb 来尝试我的第一个应用程序，并且我正在权衡 STI 模型上的选项，如下所示。

它工作得很好，我当然会以比我目前数不清的更多方式添加到此，我只是好奇如果使用嵌入式文档或类似的东西不会更好。

我希望我的模型尽可能多地共享 IE，因为它们都继承了某些属性，property/_form.html.erb 上的共享表单部分...除了它们自己独特的表单元素等之外。我知道这些视图会有所不同，但我还不确定控制器，因为我可以使用我假设的属性控制器来处理大多数事情？我确信随着我的进展，事情会变得更加复杂。

任何指示资源和/或智慧（省痛技巧）将不胜感激

property.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

Answer 1

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

例如，您的 Property 模型似乎做了很多事情。为什么不将您所处理的地理信息拆分到嵌入式文档中（纬度、经度、地址等）？这样您的代码将保持更简单且更具可读性。

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

关于你的 food_types 和 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

Answer 2

您是否希望在同一查询中返回餐馆和酒吧？

如果不是，您可能需要重新考虑让它们从基类型派生。

默认情况下，Mongo_Mapper 会将餐厅和酒吧放在一个集合中。这可能会影响性能并使未来更难扩展。

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