ruby-on-rails - mongodb数据设计问题

标签 ruby-on-rails ruby database-design mongodb mongomapper

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

它工作正常,我当然会以比我目前能计算的更多的方式对此进行添加,我只是想知道如果我使用嵌入式文档或类似的东西会不会更好。

我希望我的模型尽可能多地共享,IE,因为它们都继承了某些属性,属性/_form.html.erb 上的共享表单部分......除了它们自己独特的表单元素等。我知道 View 会有所不同,但我还不确定 Controller ,因为我可以使用我假设的大多数事情的属性 Controller ?而且我敢肯定,随着我的进行,它会变得更加复杂。

任何指针资源和/或智慧(省痛技巧)将不胜感激

属性.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

最佳答案

不要害怕更多的模型,OO 的理念是能够将您的关注点分解成小块,然后以需要处理的方式处理它们中的每一个。

例如,您的 Property 模型似乎做了很多事情。为什么不将您正在进行的地理信息拆分成一个 EmbeddedDocument(纬度、经度、地址等)?这样您的代码将保持更简单和更易读。

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

关于您的 cuisine_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

关于ruby-on-rails - mongodb数据设计问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2263149/

相关文章:

ruby-on-rails - Rails 3.1 + 设计 : The default routes for Devise aren't working

ruby - 如何使用带有 cron 的 rbenv 运行 Ruby 脚本

ruby-on-rails - capybara webkit 驱动程序中的 javascript 确认对话框

mysql - 将定义选项的子集存储到另一个表列中

mysql - 需要数据库设计建议

javascript - 使用模板语法防止 mustache.js 模板加载图像

ruby-on-rails - Acts_as_taggable_on 索引太长

ruby-on-rails - Heroku-toolbelt 安装在我的 mac OS X 中出错

ruby - 如何使用 RSpec 测试文件创建?

c# - 数据库的正确模型,每个用户都有一个表