#ruby-on-rails #mongodb #schema #social-networking #mongoid
#ruby-on-rails #mongodb #схема #социальные сети #mongoid
Вопрос:
Привет, друзья ~ Я хочу использовать MongoDB для реализации модели дружбы на основе групп. Нравится Google Buzz. Например,
меня зовут Том, Стив и Гэвин — мои друзья. Стив — мой одноклассник и коллега, Гэвин — мой коллега.
Том -Групповые одноклассники Стив -Коллективные сотрудники Стив Гэвин
Мой вопрос в том, как разработать эту схему?
В rails и Mongoid я написал следующий код:
Вот user.rb
пользователь класса включить Mongoid::Document поле: имя пользователя поле: электронная почта поле :block_list, :type => Array, :default => [] ключ: имя пользователя embeds_many :группы embedds_many :pending_requests has_and_belongs_to_many :друзья, :имя_класса => "Пользователь" завершение
group.rb
класс Group включить Mongoid::Document embedded_in :пользователь поле: имя поле : участники, :тип => Массив, :по умолчанию => [] завершение
pending_request.rb
запрос запроса класса включить Mongoid::Document embedded_in :пользователь поле: имя пользователя поле: тело завершение
Есть предложения? Спасибо.
Ответ №1:
Есть несколько способов, которыми вы могли бы разработать схему для этой цели. Один из важных вопросов, который следует задать, заключается в следующем: если Том говорит, что Гэвин — коллега, означает ли это, что Гэвин также покажет Тома как коллегу?
Да: если Том или Гэвин могут создать ссылку между ними двумя, и это одна и та же ссылка в любом случае (независимо от процесса создания этой ссылки), тогда то, о чем вы действительно говорите, — это отношения. Mongo — это база данных NoSQL и не выполняет объединения, поэтому вам пришлось бы управлять этими отношениями с помощью нескольких запросов select и update. Том мог бы вести список коллег, а Гэвин мог бы вести список коллег, и в любое время, когда один из них добавлял другого, оба документа нуждались бы в обновлении. Честно говоря, такого рода отношения — это то, в чем хороши реляционные базы данных. Mongo, вероятно, не лучшее решение.
Нет: если Том может определить, является ли Гэвин коллегой, совершенно независимо от того, что думает Гэвин, тогда вам следует сохранить массив коллег в вашей коллекции пользователей. То же самое касается одноклассников. В каждом пользовательском документе должно быть поле name, поле coworkers, поле classmates и т.д. Чтобы получить информацию о Томе, вам нужно всего лишь извлечь один документ из одной коллекции, и у вас есть все.
Имейте в виду, что отслеживание взаимосвязей между документами не является сильной стороной Mongo. Если вам приходится иметь дело с большим количеством взаимосвязей и относительно небольшими документами, Mongo действительно не лучший выбор.
Нет ничего плохого в использовании MySQL для управления пользователями и отношениями при хранении журналов активности, комментариев, сообщений и т.д. В Mongo.