Найкращий спосіб створити базу даних та таблицю, щоб вести облік змін?

Мені потрібно налаштувати функцію історії проекту, щоб відстежувати попередні зміни.

Скажімо, у мене зараз дві таблиці:

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

Приклад: у мене є рядок у примітках, і користувач хоче змінити повідомлення. Я хочу слідкувати за його станом до зміни та після зміни.

Який найкращий підхід до створення стовпця в кожній із цих таблиць, де буде сказано, чи елемент "старий". 0, якщо активний АБО 1, якщо видалений / невидимий.

Я також хочу створити AUDIT TRAILтаблицю історії ( ), яка містить idпопередній стан, idновий стан, до якої таблиці відносяться ці ідентифікатори?

Будь ласка, перегляньте

http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

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

Ми можемо відслідковувати, які рядки були змінені в нашій системі PTA (Point in Time), додаючи деякі стандартні стовпці PTA (у часі) до всіх таблиць, що цікавлять PTA.

Я пропоную наступне:

DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.

При розробці можливостей версій у ваших даних є кілька мінімальних (я думаю) вимог:

• Кожна версія даних повинна бути автономною та незалежною від інших версій. Це означає, що жоден прапор чи інший індикатор не показує, що є поточною версією та які є "історією". Це також означає, що оновлення об'єкта означає лише вставлення нової версії - не потрібно оновлювати попередні версії.
• Уникайте того, що я називаю залежною від рядка залежністю. Ось де одне поле (End_Date) рядка повинно залишатися синхронізованим з іншим полем (Start_Date) іншого рядка. Це ускладнює роботу з даними та є прекрасним джерелом аномалій.
• Поточна версія та всі попередні версії повинні бути в одній таблиці. Це дає можливість використовувати той же запит для перегляду минулих даних "станом на" певної дати та для перегляду поточних даних.
• Іноземні ключі даних, які були перетворені, повинні працювати так само, як і звичайні (неперевершені) дані.
• Дизайн повинен бути настільки простим або загальновизнаним, що крива навчання для нових розробників зводиться до мінімуму.

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