Многопользовательские разрешения для других объектов

Question

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

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

1. отношениях владения лицом к продукту (FK)
2. отношением лица к продукту через таблицу моста Person_Product
3. отношение «человек-группа к продукту», когда продукт принадлежит одной и только одной группе
4. лицо-организация (полномочия для широкого применения), которые являются разрешениями пользователей по умолчанию, если разрешения через другие отношения не объявлены.

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

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

Прав ли я в этом мышлении?Или мы на правильном пути сейчас?Будем весьма благодарны за любые полезные материалы.

Соответствующие технологии помечены.

Answer 1

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

Мой подход заключается в том, чтобы иметь строго нормализованную часть БД, содержащую фактические данные, и ненормализованную часть, которая действует как кэш ... обновления между этими двумя частями осуществляются одним способом: от нормализованной части до кеша (в случае, если несогласованных данных / аномалий в cahce, кеш можно перестроить)

преимущество в том, что ваши разрешения для пользователя могут быть агрегированы (возможно, даже как двоичный объект) и извлечены как одна строка для пользователя / для продукта / и т. Д., Если разрешения поступают из кэша ... в зависимости в случае использования это может быть очень быстро

недостаток: обновления кешированных данных более сложны: вам нужно обновить обычную БД, а затем вам придется обновить кеш, иначе ваше обновление не будет видимо кешу, пока оно не будет переброшено ... это нет больших проблем, если ваши разрешения не обновляются каждые 2 секунды

плюс: вы должны внедрить и поддерживать кеш и приложения, которые используют это ...

Итак, одно предупреждение: даже если этот может (== это не обязательно будет в каждом случае) очень быстрым, вы не должны использовать этот подход, пока остаются какие-либо другие опции. (Вы должны избегать нарушения нормализации так долго, как можете; правильно ли проиндексирована БД? Может ли такой кэш быть настроен где-то еще, т. е. где-нибудь приложение-служба?)