|
|
|
Лог измененения таблиц.
|
|||
|---|---|---|---|
|
#18+
Есть база данных, которая находится на начальной стадии проектирования. В будущем планируется вести лог изменения некоторых таблиц, необходимо будет знать когда и кто добавил, изменил или удалил запись. На у приходит два варианта: Тригерами, то есть добавить ещё одну таблицу с перефиксом _log куда будет скидываться преведущий вариант строки. Второй ввести в таблицу дополнительные поля dn - дата начала do - дата окончания. И вместо удаления записи делать update поля do. Может быть есть варианты. Вот думаю какой лучше выбрать, хотелось бы знать с какими проблемами я могу столкнуться при использовании того или иного метода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2015, 13:22 |
|
||
|
Лог измененения таблиц.
|
|||
|---|---|---|---|
|
#18+
Чигиваранеобходимо будет знать когда и кто добавил, изменил или удалил запись. .... добавить ещё одну таблицу с перефиксом _log куда будет скидываться преведущий вариант строки. Для начала определись: достаточно ли тебе когда и кто или таки нужен полный протокол изменений. Потом определись как долго эта информация должна храниться. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2015, 13:25 |
|
||
|
Лог измененения таблиц.
|
|||
|---|---|---|---|
|
#18+
Да нужен полный протокол, информация должна храниться вечно. Ещё забыл написать СУБД Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2015, 13:27 |
|
||
|
Лог измененения таблиц.
|
|||
|---|---|---|---|
|
#18+
тогда почитай про archivelog и log miner. В Оракуле всё уже украдено до Вас. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2015, 13:33 |
|
||
|
Лог измененения таблиц.
|
|||
|---|---|---|---|
|
#18+
Чигивара, Тут надо исходить из того на сколько "широкая" у вас таблица и какое количество полей у вас будет меняться. первый вариант(ваш) подойдет если меняется бОльшая часть строки в таблице. Плюс можно сохранять только изменившиеся значения, а в остальных писать null, он занимает 1 байт, а в некоторых случаях и вообще 0. второй вариант оптимален только тогда когда вам важны ссылки на историчные данные. В остальных случаях только минусы (в перемешку историчные и актуальные данные, нужно всегда это учитывать при запроса, удар по производительности, отсутствие внешних ключей и т.д.) есть третий вариант, если у вас допустим меняется только пару полей из всей таблицы (например какой то статус и дата этого статуса) то целесообразно вынести это в отдельную таблицу (например история статусов). Если полей мало, но они всегда разные можно изменения хранить как id записи, название поля(либо номер), старое значение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2015, 13:44 |
|
||
|
Лог измененения таблиц.
|
|||
|---|---|---|---|
|
#18+
ЧигивараДа нужен полный протокол, информация должна храниться вечно. Ещё забыл написать СУБД Oracle. Вы пробовали прикрутить к этому делу оракулячий флешбек датабейз архив? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2015, 20:53 |
|
||
|
Лог измененения таблиц.
|
|||
|---|---|---|---|
|
#18+
ЧигивараМожет быть есть варианты. мы решаем такую задачу путем создания исторической таблицы (причем у нас история ведется по разнородным данным, поэтому в центре одна общая таблица и от нее расходятся звездой специфические. В центральной таблицы как раз есть дата начала и конца действия записи. Заполнение происходит не по триггеру, а приложением, которое собственно корректирует данные - оно параллельно текущую таблицу корректирует и историческую. Таким образом в истории есть все данные, включая на текущий момент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2015, 10:42 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=17&tid=1540421]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
15ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 16ms |
| total: | 161ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...