У меня есть таблица, содержащая роли. Многие ролики могут быть назначены роли. Разрешения могут быть назначены роли, предоставляя всем пользователям эту роль с разрешением.Какие недостатки существуют для поддержания таблицы вычисленных записей с триггерами и ограничениями FK?
Когда я назначаю разрешение на роль, состоящую из 500 сотен человек, я создал 500 разрешений.
С каждым разрешением, назначенным роли, я указываю комплексный расчет, который должен иметь место при определении того, какой тип доступа разрешен каждому человеку с этой ролью. Например, если я назначаю «READ_EMAIL» разрешение роли «ACCOUNTANT», в то время, когда я это делаю, я также включаю переменную, которая указывает, какие типы почтовых ящиков разрешены, поскольку существует несколько типов почтовых ящиков, и бухгалтеры должны иметь доступ к определенной группе из них.
Поэтому, когда я хочу узнать, какие люди имеют доступ к определенным почтовым ящикам, я должен не только присоединяться к моим разрешениям, ролям и таблицам пользователей, но мне нужно сделать поиск по причинам, которые трудно объяснить в пространство здесь занимает много времени и не может быть сделано быстрее.
Проблема, с которой я сталкиваюсь, заключается в том, что, когда я раскрываю все расчетные разрешения в представлении (объединение всех этих таблиц + выполнение сложного, трудоемкого вычисления), это занимает очень много времени.
Мне пришло в голову, что я могу просто создать таблицу прав пользователя, которая заполняется через триггеры, активируемые назначением пользователя роли или назначением разрешения роли. Всякий раз, когда разрешение назначается роли, оно вставляет запись для каждого человека, имеющего эту роль, и будет выполнять сложный поиск в это время, помещая 500 записей в эту таблицу. Всякий раз, когда пользователь назначается роли, он генерирует любые разрешения + сложные поисковые запросы. Были бы внешние ключи из этой таблицы в таблицу назначения ролей и таблицы назначения разрешений с каскадным удалением.
Разрешение на назначение роли редки, поэтому это нормально, если это значительно замедляется. 99.99999% доступа к моим таблицам - SELECT.
Любые недостатки этого метода? Мне нужны данные в реальном времени. Я просто разрабатываю собственное материализованное представление on-commit? Любые другие предложения?
Мы не очень опытные материализованные виды, и я не знаю всех потенциальных проблем, с которыми я могу столкнуться. Будет ли исключение при создании материализованного представления пузыря и откат транзакции, выполняющей вставки? Я даже не уверен, что еще может быть проблемой. Я просто знаю, что мне нужны данные в реальном времени во все времена, и если по какой-то причине ситуация перестает синхронизироваться, это будет проблемой. –
@ Renderln: Добавлено в мой ответ –