Проблема моделирования на основе разрешений MongoDB

Question

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

Моя модель данных требует некоторой гибкости, поэтому я в настоящее время изучаю возможность использования либо модели EAV, либо хранилища документов в MongoDB.

Вот мои основные требования:

• Пользователи смогут хранить и делиться своими любимыми вещами (телепрограммы, веб-сайты, песни и т. Д.).
• Список возможных «вещей», которые может хранить пользователь, неизвестен. Например, пользователь может захотеть сохранить свое любимое животное.
• Пользователи могут делиться своими любимыми вещами с другими пользователями. Тем не менее, пользователь может решить, чем он / она делится друг с другом. Например, пользователь может поделиться своим любимым фильмом с одним пользователем, но не с другим.

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

Я много работал с Magento, который широко использует модель EAV. Однако я добавляю еще один уровень сложности, ограничивая, какие пользователи могут видеть какую информацию.

Меня сразу тянет к MongoDB, так как формат без схемы дает мне необходимую гибкость. Однако я не уверен, насколько простым (или эффективным) будет доступ к данным после их сохранения. Я также обеспокоен тем, как будут обрабатываться изменения данных, например, пользователь меняет свой любимый фильм.

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

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

Спасибо, что прочитали это далеко, и, пожалуйста, дайте мне знать, если я могу предоставить больше информации.

С уважением,

Рыба

Answer 1

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

Если вам просто нужно отфильтровать некоторые значения при просмотре профиля пользователя, один документ для каждого пользователя будет работать достаточно хорошо, причем у каждого избранного есть список авторизованных идентификаторов пользователя / группы, который применяется в коде приложения. , В этом случае и чтение, и запись являются отдельными операциями над известным документом, поэтому они будут быстрыми.

Если вам нужны просмотры по нескольким профилям, ваш основной документ, вероятно, должен быть любимым. Вам нужно будет настроить правильные индексы, но производительность не должна быть проблемой.

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