вопрос дизайна данных mongodb - PullRequest
Новая
       17

вопрос дизайна данных mongodb

2 голосов
/ 15 февраля 2010

Я пробую свое первое приложение с mongodb на Rails, используя mongo_mapper, и я взвешиваю свои варианты для модели STI, как показано ниже.

Это прекрасно работает, и я, конечно, добавлю к этому больше способов, чем могу сосчитать, мне просто любопытно, не лучше ли мне было бы использовать встроенные документы или что-то подобное.

Я бы хотел, чтобы мои модели имели как можно больше общего доступа, т.е. IE, поскольку все они наследуют определенные атрибуты, частичную форму общего доступа для свойства / _form.html.erb ... в дополнение к своим собственным уникальным элементам формы и т. Д. I знаю, что представления будут отличаться, но я еще не уверен в контроллерах, так как я мог бы использовать контроллер свойств, который я предполагаю для большинства вещей? И я уверен, что со временем все будет сложнее.

Будем весьма благодарны за любые ресурсы и / или мудрость указателей (советы по экономии боли)

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

Ответы [ 2 ]

3 голосов
/ 15 февраля 2010

Не бойтесь большего количества моделей, идея ОО состоит в том, чтобы иметь возможность разделить ваши проблемы на мелкие кусочки, а затем обработать каждую из них так, как они должны быть обработаны.

Например, ваша модель Property, кажется, делает очень многое. Почему бы не разделить географию, которую вы используете, на EmbeddedDocument (lat, lng, address и т. Д.)? Таким образом, ваш код останется более простым и читабельным.

Я сам использую этот вид ИППП и обнаружил, что он делает мой код намного проще и удобнее. Одна из преимуществ использования такой базы данных, как Mongo, заключается в том, что вы можете делать очень сложные STI, подобные этой, и при этом иметь управляемый сбор данных.

Относительно ваших kitchen_types, beers_on_tap и т. Д., Я думаю, что это прекрасные понятия. Также может быть полезно иметь модели Kitchen и Beer, чтобы ваша база данных оставалась более нормализованной (концепция, которую легко потерять в Mongo). e.g.:

class Bar < Property
  key :beer_ids, Array
  many :beers, :in => :beer_ids
end
class Beer
  include MongoMapper:Document
  key :name, String
end
0 голосов
/ 24 февраля 2010

Ожидаете ли вы вернуть рестораны и бары в одном запросе?

Если нет, вы можете пересмотреть вопрос о том, чтобы они были производными от базового типа.

По умолчанию Mongo_Mapper собирается поместить и рестораны, и бары в одну коллекцию. Это может снизить производительность и усложнить масштабирование в будущем.

Просматривая часть кода Mongo_Mapper, кажется, что вы можете установить это на лету с помощью set_collection_name.

...