Никогда не удаляйте реляционную схему БД

Question

Я рассматриваю проектирование схемы реляционной БД для БД, которая фактически никогда ничего не удаляет (устанавливает флаг удаления или что-то еще).

1) Какие столбцы метаданных обычно используются для размещения такой архитектуры?Очевидно, логический флаг для IsDeleted может быть установлен.Или, может быть, лучше всего использовать временную метку в столбце «Удаленные», или, возможно, и то, и другое.Я не уверен, какой метод вызовет у меня больше проблем в долгосрочной перспективе.

2) Как обычно обрабатываются обновления в таких архитектурах?Если вы пометите старое значение как удаленное и вставите новое, вы столкнетесь с уникальными проблемами ограничения PK (например, если у вас есть идентификатор столбца PK, то новая строка должна иметь такой же идентификатор, как и тот, который вы только что отметили как недействительный, илииначе все ваши внешние ключи в других таблицах для этого идентификатора станут бесполезными).

Answer 1

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

Answer 2

Вот некоторые дополнительные вопросы, которые вы также хотите рассмотреть

1. Как часто происходит удаление. Каков ваш бюджет производительности? Это может повлиять на ваш выбор. Ответ на ваш дизайн будет отличаться в зависимости от того, удаляет ли пользователь одну строку (например, скажем, ответ на сайте вопросов и ответов или почасовое удаление записей из канала)

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

3. Как будут работать ограничения внешнего ключа. Может ли одна таблица ссылаться на другую таблицу, в которой есть удаленная запись?

4. Когда вы добавляете или изменяете существующие таблицы, что происходит с удаленными записями?

Как правило, системы, которые очень заботятся о проверке, используют таблицы, как упоминал Стив Прентис. Часто в каждом поле из исходной таблицы все ограничения отключены. В нем часто будет поле действия для отслеживания обновлений и удалений, а также отметка даты / времени изменения вместе с пользователем.

Пример см. В таблице PostHistory по адресу http://data.stackexchange.com/stackoverflow/query/new

Answer 3

1. Я сделал это.

2.a) номер версии несколько решает проблему уникальных ограничений, хотя на самом деле это просто ослабляет уникальность, не правда ли.

2.b) вы также можете архивировать старые версии в другую таблицу.

Answer 4

Я думаю, что то, что вы ищете здесь, обычно называют "знакомством со знаниями".

В этом случае вашим первичным ключом будет ваш обычный ключ плюс дата начала знаний.

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

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

При «удалении» вы просто устанавливаете дату окончания «сейчас».