Дизайн таблицы истории SQL - программирование
Подтвердить что ты не робот

Дизайн таблицы истории SQL

Мне нужно создать таблицу истории, чтобы отслеживать несколько значений, которые были изменены на определенной записи при редактировании.

Пример:
Пользователю предоставляется страница для редактирования записи.

Название: Mr.
Имя: Джо
Tele: 555-1234
DOB: 1900-10-10

Если пользователь меняет любое из этих значений, мне нужно отслеживать старые значения и записывать новые.

Я думал об использовании таблицы следующим образом:

История
---------------

Id
modifiedUser
ModifiedDate
TABLENAME
RecordId
OldValue
новое_значение

Одна из проблем заключается в том, что он будет иметь несколько записей для каждого редактирования. Я думал о том, что для их группировки нужно иметь еще одну таблицу, но у вас все еще есть одна и та же проблема.

Я также думал о сохранении копии строки в таблице истории, но это тоже не кажется эффективным.

Любые идеи?

Спасибо!

4b9b3361

Ответ 1

Вы должны определить, какой тип эффективности вам интересен: вы можете иметь эффективность пространства для хранения, эффективность усилий, необходимых для записи истории (транзакционных издержек), или эффективность времени для запроса истории записи в конкретным способом.

Я заметил, что у вас есть имя таблицы в предлагаемой таблице истории, это подразумевает намерение записать историю более чем одной таблицы, что исключает возможность хранения точной копии записи в вашей таблице истории, если только все из отслеживаемых таблиц всегда будет иметь одинаковую структуру.

Если вы имеете дело с столбцами отдельно, то есть вы записываете только одно значение столбца для каждой записи истории, вам придется разработать полиморфный тип данных, который способен точно представлять каждое значение столбца, с которым вы столкнетесь.

Если эффективность пространства для хранения является вашей главной задачей, я бы разбил историю на несколько таблиц. Это означало бы наличие новой таблицы значений столбцов, связанной как с таблицей событий редактирования, так и с таблицей определения столбцов. В таблице событий редактирования будет записана метка пользователя и времени, таблица определения столбца будет записывать таблицу, столбец и тип данных. Как отметил @njk, вам не нужно значение старого столбца, потому что вы всегда можете запросить предыдущее редактирование, чтобы получить старое значение. Основная причина, по которой этот подход должен был сэкономить, - это предположение, что, вообще говоря, пользователи будут редактировать небольшое подмножество доступных полей.

Если эффективность запросов - ваша главная задача, я бы установил таблицу истории для каждой таблицы, которую вы отслеживаете, и добавьте поле статистики пользователя и времени в каждую таблицу истории. Это также должно быть эффективным с точки зрения стоимости транзакции для редактирования.

Ответ 2

Я бы рекомендовал, чтобы для каждой таблицы, которую вы хотите отслеживать историю, у вас есть вторая таблица (т.е. tblCustomer и tblCustomer_History) с одинаковым форматом - плюс столбец даты.

Всякий раз, когда делается редактирование, вы вставляете старую запись в таблицу истории вместе с датой/временем. Это очень легко сделать и требует небольших изменений кода (обычно это просто триггер)

Это позволяет сохранить ваши "реальные" таблицы как можно меньше, но дает вам полную историю всех изменений, которые были сделаны.

В конечном счете, однако, это будет связано с тем, как вы хотите использовать эти данные. Если это справедливо для целей аудита, этот метод прост и имеет мало недостатков, кроме дополнительного дискового пространства и незначительного влияния на вашу основную систему или вообще никакого влияния на нее.

Ответ 3

Вам не нужно записывать старое и новое значение в таблицу истории. Просто запишите новейшее значение, автора и дату. Затем вы можете получить самую последнюю запись для некоторого user_id в зависимости от даты записи. Это может быть не лучший подход, если вы будете иметь дело с большим количеством данных.

пользователь (id, user_id, datetime, author,...)

Примеры данных

id  user_id  datetime          author  user_title  user_name  user_tele ...
1   1        2012-11-05 11:05  Bob
2   1        2012-11-07 14:54  Tim
3   1        2012-11-12 10:18  Bob