Таблиця історії бази даних / Таблиця відстеження

В даний час я хочу структурувати таблицю відстеження / історії так:

• PrimaryKey - ідентифікатор
• OtherTableId - fk
• fieldName - назва поля його відстеження
• OldValue
• NewValue
• UserName
• CreateDateTime

Тому в основному я хочу мати таблицю, яка буде відслідковувати іншу історію таблиць, зберігати назву стовпця зміненого поля з новим і старим значенням. Моє запитання, чи може хтось пробивати дірки в цьому? Крім того, який найпростіший спосіб забезпечити, щоб у стовпчик fieldName було введено лише ім’я стовпця з таблиць, за яким його відстеження? Наразі мої варіанти полягають у тому, щоб мати перелік у службі, яку я будую, або створити іншу таблицю статусу та зробити полеName fk. Якісь кращі ідеї?

Редагувати ціль. Наразі існує лише 2 поля, які ми хочемо відстежити. Одне поле буде показане на веб-сторінці для відображення історії, до іншого поля буде доступний лише один відділ, і вони мають доступ до перегляду бази даних, яку вони зможуть запитувати. Вони запитують саме це поле, щоб отримати інформацію про те, хто змінив поле і що робити. З цієї причини ми хотіли встановити його там, де поле бази даних визначає стовпчик таблиці, а не точну копію історії записів таблиці. Ми хочемо лише відстежити два поля з можливостями додавання або видалення полів у майбутньому.

Спасибі!

Пробивання отворів: що робити, якщо схема бази даних буде змінена в той самий момент пізніше, а ім'я стовпця зміниться або стовпець буде видалено повністю? Багато систем бази даних це дозволяють. Що буде тоді з вашим "fieldName"?

Щодо цілісності даних: ви повинні переконатися, що кожна операція з оновлення або видалення обов'язково оновлює вашу таблицю відстеження. Це найкраще досягти за допомогою тригерів, викликаючи збережену процедуру. Ви повинні переконатися, що лише ті збережені процедури мають доступ до запису вашої таблиці відстеження, тому ніхто більше не може записати неправильні значення.

Якщо ви можете жити за допомогою конкретного рішення для постачальника db: у більшості систем db є системні таблиці, де зберігається інформація про схеми (назви таблиць, ідентифікатори таблиць, назви стовпців тощо). Ви можете перевірити, чи можна встановити посилання іноземного ключа на таку системну таблицю. Це дозволить замінити ім'я поля на ідентифікатор поля, якщо база даних підтримує щось подібне.

Насправді, якщо вам потрібно відстежувати цілі рядки конкретної таблиці, включаючи всі стовпці (а не лише невелику підмножину стовпців), слід врахувати пропозицію @ sarfeast. Прочитайте цю статтю про недоліки моделей-парних імен.

Найуспішніша реалізація аудиту змін (відстеження історії), яку я бачив, є менш загальною та набагато простішою. Він передбачає створення таблиці журналів змін для кожної таблиці, яку ви хочете контролювати, зберігаючи однакові назви стовпців та типи даних (з додатковим стовпцем для часової позначки).

Кінцева мета, тобто те, що ви хочете зробити з аудитованими даними, допоможе оцінити, наскільки підходящим може бути кожен підхід.

Коротше кажучи: вам потрібно встановити механізм аудиту для таблиць, за якими потрібно відстежувати зміну значення.

Таблиця єдиного аудиту :

Створіть таблицю для реєстрації імені таблиці, імені поля, abd старої та нової версій даних. Для цього методу зазвичай реєструвати як старі, так і нові версії даних та лише ті поля, які змінилися. Для того, щоб це реалізувати в тригерах, потрібно або первинний ключ на столі, або оновлюються лише окремі рядки.

Ось хороший пост зі сценаріями про те, як цього досягти - Створення аудиторських доріжок

Інші корисні посилання :

• Шлях аудиту - відстеження змін даних у базі даних
• Залишаючи слід аудиту у вашій базі даних

Ви можете перевірити проектну документацію NHibernate Envers щодо ідей.

В основному у вас є одна таблиця ревізії, куди ви можете додавати додаткові дані, наприклад, часова мітка або користувач. Потім кожна таблиця, яку ви відстежуєте, отримує додаткову таблицю аудиту з усіма стовпцями, fk до таблиці перегляду та типом редагування (додавання, зміна, видалення). AFAIK, ви б не хотіли, щоб у ваших таблицях аудиту був фактичний FK в реальній таблиці, оскільки це не дозволило б видалити.