|
|
|
Вычисление способа удаления внутри триггера
|
|||
|---|---|---|---|
|
#18+
Здравствуйте уважаемые гуру ! В связи со скудностью информации по PostgreSQL на понятном языке, вынужден обращаться к Вам за помощью --------------- Стоит задача блокирования возможности физического удаления записей в таблицах базе данных НО с возможностью чистки таблиц. С целью реализации такого способа удаления, в каждую таблицу БД было введено поле "валидность" строки которое принимает одно из двух значений Y - запись видно в приложении, N-запись не видно в приложении (отфильтровывается в запросах). Технология простенькая но возникает проблема с подчинёнными (detail) таблицами, которые имею очень "ветвистую структуру". По умолчанию написан следующий "скелет" триггерной функции Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Проблема: При удалении материнской записи в первый раз, она отмечается признаком valid=N, действие по удалению блокируется что приводит к тому, что тригерры в подчинённых таблицах просто не срабатывают. При повторном удалении - тригерр в подчинённой таблице срабатывает впервые и "ставит" признак невалидности подчинённой записи, а "внучатая" запись пока не знает что "выше" происходит удаление. Вопрос: Каким образом сгенерировать событие "удаление" для подчинённых записей таблицы, без самого удаления материнской записи. ...или подскажите какую то иную технологию выхода из ситуации. Сразу оговорюсь, проверка ссылочных полей не прокатывает по простейшей причине - связи между таблицами очень сложные и не всегда зависят от простого отношения master-Detail буду благодарен за любую мысль на эту тему ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 19:17 |
|
||
|
Вычисление способа удаления внутри триггера
|
|||
|---|---|---|---|
|
#18+
judas777, Заведите отдельного пользователя для чистки и не мучайтесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 10:49 |
|
||
|
Вычисление способа удаления внутри триггера
|
|||
|---|---|---|---|
|
#18+
NikolayV81judas777, Заведите отдельного пользователя для чистки и не мучайтесь Николай, проблема не в пользователе, а в том, чтоб если нужно удалить строку БД нужно вырубать триггеры. Встречный вопрос. Каким образом получить полный перечень активных (ENABLED) триггеров для таблицы ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 18:24 |
|
||
|
Вычисление способа удаления внутри триггера
|
|||
|---|---|---|---|
|
#18+
judas777, NikolayV81 имеет ввиду следующее: запретить удалять всем пользователем, кроме специально обученного. Т.о. в триггере можно проверять пользователя, а на "valid". (Кстати, прикинте, что произойдет, когда два пользователя откроют табличку, сходят покурить, а затем почереди нажмут удалить?) Продолжаю про пользователя: если привелигированный удаляет - удаляем, нет обновляем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 18:47 |
|
||
|
Вычисление способа удаления внутри триггера
|
|||
|---|---|---|---|
|
#18+
Gold_judas777, NikolayV81 имеет ввиду следующее: запретить удалять всем пользователем, кроме специально обученного. Т.о. в триггере можно проверять пользователя, а на "valid". (Кстати, прикинте, что произойдет, когда два пользователя откроют табличку, сходят покурить, а затем почереди нажмут удалить?) Продолжаю про пользователя: если привелигированный удаляет - удаляем, нет обновляем. я так понял пометка в принципе вводилась длч того что-бы решить проблему удаления не в том месте, если так, то просто забираем права на удаление у таблиц у всех пользователей кроме userwhocandeleterecords ( можно просто роль, которая по дефолту будет вырублена ), при необходимости "почистить" делаем второй коннект нужным пользователем ( подключаем роль ) и удаляем. В таком случае триггеры вообще не нужны ( если связи правильно прописаны ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2014, 18:51 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38838460&tid=1998278]: |
0ms |
get settings: |
5ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
180ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
2ms |
| others: | 197ms |
| total: | 454ms |

| 0 / 0 |
