CQRS при чтении с разрешениями для большого набора данных

Question

Я пытаюсь понять, как сторона чтения CQRS может работать с большим приложением для управления документами (видео / pdf файлы / и т. Д.), Которое мы пишем.

Мы хотим показать список всех документовкоторый пользователь имеет разрешение на редактирование (то есть показывает все документы, которые пользователь может редактировать). Может быть 10000 документов, которые может редактировать конкретный пользователь.

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

Как бы я спроектировал свою модель чтения, чтобы позволить мне быстро получить документы, которые я могу редактировать для конкретного пользователя?

В настоящее время я вижу таблицу с моими документами, другую - пользователей и другую таблицу, связывающую роль «редактирования» между пользователем и документами.Поэтому я делаю объединения, чтобы получить данные для этого экрана.

Кроме того, могут быть роли для удаления, просмотра и т. Д.

Это правильный путь в этом случае?

JD

Answer 1

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

SELECT * FROM documents_editable_by_user WHERE UserId = @UserId
SELECT * FROM documents_deletable_by_user WHERE UserId = @UserId
SELECT * FROM documents_visible_for_user WHERE UserId = @UserId

Но вы даже можете динамически создать таблицу / список для каждого пользователя в хранилище модели чтения.Это становится довольно легко, когда вы переключаетесь из хранилища для чтения на основе SQL в NoSQL (если вы этого еще не сделали).

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

Answer 2

Когда у меня была модель чтения, которая приняла форму фильтрующей поисковой формы (каламбур не предназначен), я использовал rhino-security в качестве основы службы авторизации.

Я настроил систему так, чтобы таблицы службы авторизации передавались через систему pub-sub системы SQL Server и агент SQL Server клиентам, которые частично отображали денормализованные данные - тогда я разрешил Rhino.Security объединить модель авторизации в модель чтения для каждого пользователя.

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