|
|
|
Вопрос по триггерам
|
|||
|---|---|---|---|
|
#18+
В БД есть понятия Клиент (таблица CUSTOMERS), Счет (таблица ACCOUNTS), Услуга (таблица SERVICES) и другие сущности. Клиент может принадлежать какой-то определенной группе (CUSTOMERS.GROUP_ID). В БД работают пользователи, права доступа которых определяются на уровне клиентской группы (например к одной группе у пользователя доступа нет вообще, в другой группе доступ только на просмотр, в третьей группе доступны все действия, кроме удаления). В таблицах ACCOUNTS и SERVICES тоже есть поле GROUP_ID, по всей видимости оно выполняет вспомогательные функции, т.к. в пользовательском интерфейсе не предусмотрена возможность задания групп в Счетах или Услугах. Группа Клиента может изменятся, в информационной системе это обеспечивает следующий программный код: Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. Программный код на Perl, суть его в том, что при изменении группы вначале обновляется CUSTOMERS.GROUP_ID, а затем обновляется GROUP_ID во всех связанных таблицах. То есть в теории GROUP_ID у всех подчиненных данных должен соответствовать CUSTOMERS.GROUP_ID. Но почему-то это происходит не всегда, видимо в информационной системе есть недоработки или баги, из-за которых GROUP_ID обновляется не всегда и CUSTOMERS.GROUP_ID может отличаться от SERVICES.GROUP_ID, что приводит к неприятным побочных эффектам (пользователи не могут редактировать Услуги, т.к. группа на Услуге отличается от группы на Клиенте, а у пользователя нет прав для работы с группой Услуги). Происходит это нечасто, время от времени я вручную синхронизирую группы подчиненных записей, но хотелось бы автоматизировать процесс. Я хочу задать для таблицы CUSTOMERS триггер на обновление поля GROUP_ID, в котором буду обновлять группу во всех подчиненных записях. Но прежде чем это делать на production-сервере, хотелось бы вначале спросить, на что вначале следует обратить внимание и какие возможны побочные эффекты. ________________________ Мы смотрим с оптимизмом... ...в оптический прицел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 11:47 |
|
||
|
Вопрос по триггерам
|
|||
|---|---|---|---|
|
#18+
И еще уточню. В приведенном коде я не вижу возможностей для описанного сбоя (когда группа Клиента и Услуги различается). Скорее всего группа обновляется еще где-то, но найти это место не представляется возможным, это больше 8 МБ исходных кодов. Я думаю, что скорее всего где-то выполняется update SERVICES set GROUP_ID = ... Поэтому вопрос такой — если я задам триггер на таблицу SERVICES, чтобы при обновлении столбцу GROUP_ID всегда присваивалось значение с родительской записи в CUSTOMERS — возможно ли тут зацикливание или взаимная блокировка? В БД триггеров нет совсем (вернее есть, но только на PK, заполнение новых значений из sequence). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 14:07 |
|
||
|
Вопрос по триггерам
|
|||
|---|---|---|---|
|
#18+
Дратути, Alibek B.В таблицах ACCOUNTS и SERVICES тоже есть поле GROUP_ID, по всей видимости оно выполняет вспомогательные функции, т.к. в пользовательском интерфейсе не предусмотрена возможность задания групп в Счетах или Услугах. Есть подозрение, что эти поля реализуют нечто похожее на механизм Oracle Label Security - выборочный доступ к данным одной и той же таблицы разными пользователями. Подозреваю, что группа у того или иного пользователя меняется не часто (как и сама таблица CUSTOMERS), т.е. ваш триггер будет вызываться редко, а значит и существенных проблем для производительности приложения не создаст. Вообще, я бы посмотрел на связи между таблицами - REFERENCE CONSTRAINTS, а то вдруг закусится ваш триггер с одним из них. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 10:25 |
|
||
|
|

start [/forum/topic.php?fid=52&gotonew=1&tid=1886353]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
36ms |
get topic data: |
7ms |
get first new msg: |
4ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 342ms |

| 0 / 0 |
