|
|
|
Логирование записей
|
|||
|---|---|---|---|
|
#18+
Товарищи, как лучше спроектировать логирование? есть несколько таблиц, по которым бы хотелось иметь историю об изменении любого поля(кто, когда). у меня на ум приходят два варианта: либо в каждой таблице пересоздавать запись с внесенными изменениями. либо сделать отдельную таблицу для этих таблиц куда будут лететь данные об изменениях. У кого был опыт в данном вопросе, подскажите как вы это решали? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 09:18 |
|
||
|
Логирование записей
|
|||
|---|---|---|---|
|
#18+
iv_roman_vlТоварищи, как лучше спроектировать логирование? есть несколько таблиц, по которым бы хотелось иметь историю об изменении любого поля(кто, когда). у меня на ум приходят два варианта: либо в каждой таблице пересоздавать запись с внесенными изменениями. либо сделать отдельную таблицу для этих таблиц куда будут лететь данные об изменениях. У кого был опыт в данном вопросе, подскажите как вы это решали? Спасибо! В этой же таблице создавать для каждой записи кучу записей со всей историей - это самый плохой вариант. Начнем с вопроса, какой у нее тогда будет первичный ключ, и какие на нее будут внешние ключи. Не взлетит. Можно для каждой таблицы делать ее такую же таблицу-лог с аналогичной структурой, и дополнительными полями - кто, когда, зачем. Громоздко, трудоемко сопровождаемо, но работать будет, и анализировать просто, даже визуально глянуть. Второй вариант, более красивый - EAV-подобный журнал: таблица, поле, было, стало, кто, когда, зачем. Чуть труднее анализ изменений - запросы к EAV замысловатые могут получиться, зато единообразное решение для всех таблиц БД. Триггера для этого дела хорошо бы сразу как-то шаблонизировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 10:35 |
|
||
|
Логирование записей
|
|||
|---|---|---|---|
|
#18+
iv_roman_vl, Решение сильно зависит от того как вы потом будете использовать этот лог... Например, хранение только изменённых полей при варианте использования, когда нужно будет получать "состояние всей строки" на момент изменения плохой выбор. С другой стороны если это просто некий аудит типа "кто поменял значение остатка 1го мая", то сойдёт. Если нужна история читайте про SCD, если не нужна попробуйте сделать прототип типа EAV (как вам уже посоветовали) только ключ источника добавьте в неё (PK или составной). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 12:36 |
|
||
|
Логирование записей
|
|||
|---|---|---|---|
|
#18+
Дедушка, Cane Cat Fisher Спасибо, большое!!! Буду читать, смотреть варианты! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2017, 14:48 |
|
||
|
Логирование записей
|
|||
|---|---|---|---|
|
#18+
все таки лучше создать копию таблицы+дата создания записи. Таким образом можете полностью логировать изменения. Со временем таблица наполнится но это небольшая проблема думаю. MS SQL имеет нативную поддержку если не ошибаюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2017, 11:48 |
|
||
|
Логирование записей
|
|||
|---|---|---|---|
|
#18+
iv_roman_vl, Event Sourcing ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2017, 14:53 |
|
||
|
Логирование записей
|
|||
|---|---|---|---|
|
#18+
Помидорвсе таки лучше создать копию таблицы+дата создания записи. Таким образом можете полностью логировать изменения. Со временем таблица наполнится но это небольшая проблема думаю. MS SQL имеет нативную поддержку если не ошибаюсь. Фишка в том, что разработчики в 90% случаев забывают, что бизнесу очень часто надо вносить изменения задним числом. Аудит это одно, историчность это другое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2017, 14:54 |
|
||
|
Логирование записей
|
|||
|---|---|---|---|
|
#18+
hVosttПомидорвсе таки лучше создать копию таблицы+дата создания записи. Таким образом можете полностью логировать изменения. Со временем таблица наполнится но это небольшая проблема думаю. MS SQL имеет нативную поддержку если не ошибаюсь. Фишка в том, что разработчики в 90% случаев забывают, что бизнесу очень часто надо вносить изменения задним числом. Аудит это одно, историчность это другое. Это никоим образом не должно повлиять на историчность данных, наоборот в некоторых случаях очень даже помогает. Для бизнес логики нужно хранить отдельные данные, например start_date, end_date. А для истории надо хранить другие данные, например created_at, updated_at. А для таблицы логирования вообще нужно еще одна колонка для хранения версии или даты создания записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2017, 19:22 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=10&tid=1540147]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
43ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 140ms |

| 0 / 0 |
