Структура базы данных при реализации архитектуры рабочего пространства в стиле Slack

Question

Я работаю над приложением с архитектурой рабочего пространства в стиле Slack, где пользователь может получить доступ к одной и той же функции приложения в нескольких «экземплярах» (рабочих пространствах).

Я собираюсь продолжить использовать Slack в качестве примера для объяснения моей проблемы.

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

Первые таблицы, которые я создаю, например «Пользователи», имеют простое отношение базы данных к рабочей области. Например, используя поле WorkspaceId в таблице Users.

Моя проблема заключается в том, что я создаю больше таблиц, которые находятся «дальше», такие как UserSettings, которые могут иметь отношение один к одному с таблицей Users. Теперь мне нужно выполнить соединение с записью Users, чтобы получить рабочее пространство, которое UserSettings запись принадлежит.

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

Поиск советов / шаблонов архитектуры, которые могут помочь в сценарии.

Answer 1

Я предполагаю, что ваша основная проблема с несколькими операторами JOIN - это снижение производительности запросов. Несколько операторов JOIN не всегда означают, что запрос будет медленным. Производительность запроса зависит от многих факторов, от того, насколько велик набор данных и насколько хорошо он проиндексирован, какой механизм базы данных и, в конечном итоге, план запроса. В результате вы получите множество операторов JOIN, если решите нормализовать базу данных таким образом. Использование полной третьей нормальной формы редко является правильным выбором для схемы из-за потенциального влияния на производительность, которое она может иметь. Некоторое дублирование данных, как правило, хорошо, компромисс, который вы делаете, это стоимость хранения по сравнению с производительностью запросов. Чтобы решить, как нормализовать базу данных, есть много вопросов, которые вы должны задать, вот некоторые из них, которые приходят на ум:

1. Какой тип запросов вы ожидаете сделать?
2. Как часто будут выполняться запросы каждого типа?
3. Как часто будут меняться данные и можно ли использовать кеш?
4. Подходит ли другая технология хранения лучше для варианта использования?
5. Являются ли некоторые данные достаточно маленькими, чтобы их можно было поместить в одну таблицу?

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