Где я должен разбить мои пользовательские записи, чтобы отслеживать изменения

Question

Я собираю базу данных сотрудников, и мне нужно иметь возможность пересматривать информацию о сотрудниках, а также отслеживать все изменения.Как я должен структурировать базу данных, чтобы иметь возможность иметь несколько ревизий одних и тех же пользовательских данных, но иметь возможность запрашивать самые последние ревизии?Я просматриваю информацию, которая редко меняется, например, Фамилия, но мне нужно будет иметь возможность запрашивать устаревшие значения.Поэтому, если Дженни Смит меняет свое имя на Дженни Джеймс, мне нужно иметь возможность найти текущую информацию пользователя при поиске по ее старому имени.

Я предполагаю, что мне понадобятся как минимум 2 таблицы, одна из которых содержитUID и другой, который содержит ревизии.Тогда я присоединяюсь к ним и опрашиваю последнюю версию.Но стоит ли разбивать его еще дальше, в зависимости от того, как часто меняются данные или тип данных?Я просматриваю около 40 полей на запись, и только одно или два поля, вероятно, изменятся при обновлении.Также я не могу удалить какие-либо данные из базы данных, мне нужно иметь возможность просмотреть все предыдущие записи.

Answer 1

Я бы использовал отдельную таблицу, потому что тогда у вас может быть уникальный идентификатор, который указывает на все другие дочерние записи, которые также являются PK таблицы, что, я думаю, снижает вероятность возникновения проблем с целостностью данных. Например, у вас есть Мэри Джонс, у которой есть записи в таблице адресов, таблице адресов электронной почты и в таблице оценки производительности и т. Д. Если вы добавите запись изменений в основную таблицу, как вы собираетесь связать всю существующую информацию? С отдельной таблицей истории это не проблема.

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

У вас также есть возможность забыть использовать предложение where Удалено = 0, где необходимо почти для каждого запроса. (Если вы используете поле удаленного флага, сделайте себе одолжение и установите представление с удаленным где = 0 и потребуйте, чтобы разработчики использовали представление в запросах, а не в оригинальной таблице.)

В поле удаленного флага вам также потребуется триггер, чтобы гарантировать, что одна и только одна запись помечена как активная.

Answer 2

Простой способ сделать это - добавить удаленный флаг, и вместо обновления записей вы устанавливаете удаленный флаг в существующей записи и вставляете новую запись.

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

Чтобы получить активную запись, запросите «где удалено = 0», влияние на скорость будет минимальным, если для этого индекса есть индекс.field.

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

Answer 3

@ Предложение Питера Тиллемана - это обычный способ выполнить то, что вы просите. Но мне это не нравится.

Структура базы данных должна отражать реальные факты, которые моделируются.

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

Подумайте только о том теплом, которое вы испытаете, когда наберете select * from employee, и ничего, кроме текущего, правильного совершенства, не вернется!