MongoDB: моделирование лайков, общих друзей и т. Д. - PullRequest
1 голос
/ 17 октября 2011

Я создаю сервис потоковой музыки, который будет иметь такие функции, как:

  • Следить за пользователями
  • Подобные песни
  • Создание и управление плейлистами
  • ... и т. Д.

Я использую Rails 3.1, Mongoid и MongoDB.Я не уверен, как мне смоделировать модели пользователей, списков воспроизведения и песен.

Между списками воспроизведения и песнями существует множество отношений.Mongoid хранит ObjectId каждой песни в массиве каждого плейлиста.Но мне нужно добавить некоторые метаданные в каждую песню <-> отношения плейлиста, например, положение песни в определенном плейлисте.

Я также не уверен, как делать такие вещи, как выяснение, какие общие друзья ивзаимные симпатии пользователя с другим пользователем.Действительно ли хорошая идея хранить пользовательские лайки и друзей внутри пользовательского документа?У пользователя может быть несколько тысяч лайков и более тысячи друзей и т. Д.

Этот тип материала лучше подходит для реляционной базы данных?

Ответы [ 2 ]

1 голос
/ 13 октября 2013

Я знаю, что этот вопрос старый, но здесь стоит иметь ответы, которые могут прочитать другие люди.

Монго был построен для таких понятий, как лайки. В хранилище документов очень легко добавлять такие функции, не прибегая к отказу от модели, данных или какой-либо миграции.

NoSQL dbs (и mongo не самый быстрый) быстро высветляются, так что вы можете воспользоваться этим и упростить вашу модель.

Я бы создал документы под названием «Песни, пользователи, лайки и плейлисты», а затем создал бы ассоциации между ними. Вы можете изменить логику в соответствии с вашим случаем, но если вы предполагаете, что список воспроизведения является общим для пользователей, но принадлежит одному пользователю, вы можете создать следующие ассоциации (в зависимости от драйвера mongo синтаксис будет разным, ниже представлен mongomapper):

 Playlists: 

 many :users, :as => :shared_with_users
 one :users, :as => :owner

 Users:

 many Playlists

Это создаст ассоциации между объектами. Под вашим объектом User вы сможете найти списки воспроизведения, связанные с этим пользователем, используя user.playlist, который будет возвращать курсор связанных объектов списка воспроизведения. Как и при использовании объекта списка воспроизведения, вы можете посмотреть на владельцев или shared_with_users, чтобы найти объекты, которые вы хотите таким образом.

0 голосов
/ 17 октября 2011

Вопрос, который вы должны задать себе в первую очередь: почему я хочу использовать mongoDB для этого приложения?

Ваша потребность кажется хорошо приспособленной для мира реляционных баз данных (= сложные отношения между объектами). Так что, возможно, вы будете счастливее с реляционной базой данных.

Есть много вариантов вашей проблемы (конечно, у каждого из них есть компромиссы):

  • Вы можете хранить свои отношения M2M в отдельной коллекции и делать некоторые клиентское соединение
  • Вы можете вставлять песни в плейлист или плейлист в песни
  • Вы можете хранить некоторые из своего плейлиста (наиболее используемый для экземпляр) в песни и на стороне клиента присоединиться к другой коллекции для наименее используемого плейлиста
  • Вы также можете хранить некоторую информацию относительно плейлиста в твоих песнях и остальных в независимом коллекция.
  • ...

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

Если вы просто создаете свое приложение, начните с чего-то очень простого (может быть, соединение на стороне клиента легко, даже если требуется больше запросов), а затем начните улучшать модель в зависимости от узких мест.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...