Какие недостатки существуют для ведения таблицы вычисляемых записей с триггерами и ограничениями FK? - PullRequest
1 голос
/ 05 октября 2010

У меня есть таблица с ролями. Многие пользователи могут быть назначены на роль. Разрешения можно назначить роли, предоставив всем пользователям эту роль с разрешением.

Когда я назначаю разрешение для роли, в которой есть 500 сотен человек, я фактически создаю 500 назначений разрешений.

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

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

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

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

Разрешение на назначение ролей встречается редко, поэтому хорошо, если это сильно замедляется. 99,9999% доступа к моим таблицам - SELECT.

Есть ли недостатки этого метода? Мне нужны данные в реальном времени. Я просто создаю свою собственную материализованную точку зрения? Любые другие предложения?

1 Ответ

2 голосов
/ 05 октября 2010

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

Ошибка обновления материализованного представления может привести к сбою операции фиксации транзакции, что приведет к откату. Таким образом, данные и материализованное представление не могут быть синхронизированы. Конечно, гораздо более вероятно, что основанное на триггерах решение приведет к ошибкам (особенно, если в несколько сеансов вносятся изменения одновременно). Я бы предпочел оставить написание логики синхронизации для Oracle.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...