Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как отследить изменения и зафиксировать их?
|
|||
|---|---|---|---|
|
#18+
Доброе время суток! К примеру есть таблица T1 с полями keyfield, field1, field2, filed3. и еще одна таблица T2 в которой отслеживаются изменения первой таблицы. Поля Т2 - Номер изменения, дата и время изменения, битовая карта изменения - допустим у нас 4 поля за которыми надо следить соответственно карта - значение 0000 до 1111 или что-то подобное, поле с хранящимися старыми значениями изменяемых полей, и поле с новыми значения изменяемых полей Т1. Можно ли в постгрисах сделать так чтобы данные об изменениях первой таблицы фиксировались во второй посредством триггеров? Если можно то хотелось бы услышать какие либо предложения по реализации сей фигни НУ И ЕСТЕСТВЕННО советы и прочие другие мысли С уважением, link_master ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 10:45 |
|
||
|
Как отследить изменения и зафиксировать их?
|
|||
|---|---|---|---|
|
#18+
С помощью триггеров все можно сделать, получается быстро и просто. Причем, если нужно делать для большого количества таблиц, то можно написать процедуру, которая сгенерирует код для триггерных процедур и самих триггеров. В своей реализации я сгенерировал функции и триггеры, которые заполняют таблицы: Код: plaintext 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. + таблицы описания структуры, которые автоматически заполняются. Получилась довольно универсальная штука, которую не нужно переделывать при переносе в БД с другой структурой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 11:20 |
|
||
|
Как отследить изменения и зафиксировать их?
|
|||
|---|---|---|---|
|
#18+
Можно ли в постгрисах сделать так чтобы данные об изменениях первой таблицы фиксировались во второй посредством триггеров? Если можно то хотелось бы услышать какие либо предложения по реализации сей фигни можно.. делаетс обычный тригер. через plpgsql не получится.. никаких имен,номеров полей он не поддерживает.. смотреть надо в сторону plperl и другие языки.. битовая карта изменения -- помойму некоректно, насколько я помню посгря(и не только посгря) не обещает что послеовательность полей сохраняется со временем.(вобщем то она конечно не меняется но забиватся на это я бы не стал) и смысл от битовой карты неясен если у тебя в одной строке только изменение одной строчки то и в битовой карте будет выставленно только одна единица,надежнее уже тогда просто запоминать имя поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 11:31 |
|
||
|
Как отследить изменения и зафиксировать их?
|
|||
|---|---|---|---|
|
#18+
...только изменение одной строчки то и в... читать как ...только изменение одного поля то и в... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 11:33 |
|
||
|
Как отследить изменения и зафиксировать их?
|
|||
|---|---|---|---|
|
#18+
А если допустим в таблице будут с помощью одного запроса изменены несколько полей? Строка то одна, но пока никто не отменял UPDATE c несколкими полями для изменения... Как быть тогда? И ты заранее не знаешь сколько полей будет изменено одно, первое и третье или все... Вот для этого я считаю и нужна битовая карта..., но не на уровне номера поля а с условным соглашением что если светится бит 1000 то меняешь поле, то которое ты считаешь первым, (не постгри а программер)... или что-то подобное... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 11:42 |
|
||
|
Как отследить изменения и зафиксировать их?
|
|||
|---|---|---|---|
|
#18+
Если изменяется несколько полей, то делается несколько записей в таблице updates. Чтобы проверить что изменилось именно это поле, а не какое-нибудь другое нужно старое значение поля сравнить с новым значением поля. В триггере для конкретной таблицы известны все имена полей этой таблицы. Можно создать таблицу описания полей в котором каждому полю присвоить числовой идентификатор (что я и сделал для упрощения работы, этого можно и не делать, можно вместо идентификаторов использовать имена). Т.е. все действия можно выполнить на plpgsql. На мой взгляд никаких битовых масок и других языков для решения этой задачи использовать не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 11:53 |
|
||
|
Как отследить изменения и зафиксировать их?
|
|||
|---|---|---|---|
|
#18+
вполне разумно... вычленять атомарные изменения (изменения одного поля) и в совокупности получить несколько записей об изменениях, самое главное при таком подходе чтобы время изменений полученных в результате одного запроса было одинаковым для всех записей, которые попадут в таблицу Updates после выполнения триггера. В этом случае такой подход может являться решением... Но вот если поле попадает в UPDATE запрос то не является ли это признаком того что оно уже призвано измениться? Допустим этот запрос генерируется оболочкой на стороне клиента, может пусть она и смотрит какое поле изменилось а какое нет и по результатам строит запрос? Спасибо ;) будем пробовать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 12:13 |
|
||
|
Как отследить изменения и зафиксировать их?
|
|||
|---|---|---|---|
|
#18+
Возможно, анализировать изменения полей со стороны оболочки проще, но есть ряд существенных недостатков: 1. Кто-то может воспользоваться другой оболочкой и внесенные изменения не будут отражены в истории. 2. При дальнейшем развитии базы данных может возникнуть ситуация когда триггер другой таблицы изменяет значение в таблице, изменения в которой вы хотите отследить. Оболочка об этом ничего не узнает и не сможет сохранить изменения в истории. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2006, 12:24 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=33760051&tid=2006343]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 230ms |
| total: | 397ms |

| 0 / 0 |
