Каковы лучшие практики для разработки таблиц БД

Question

Мы строим дизайн нашей БД (используя PostgreSQL), и для (почти) каждой таблицы у меня есть следующие столбцы

CREATE_TIMESTAMP TIMESTAMP,
CREATED_BY       VARCHAR(25),
modified_TIMESTAMP TIMESTAMP,
modified_BY       VARCHAR(25),

Я также использую таблицы аудита для некоторых таблиц сущностей. БД около 15 таблиц на данный момент (очень скоро вырастет до 50). Приблизительно для 20% этих таблиц (которые являются сущностями) нам необходимо выполнить их резервное копирование (с использованием триггеров) в ИДЕНТИЧНЫЕ копии таблиц аудита. Например: у семьи есть 1 или более «Контактов». Контакт имеет адрес электронной почты, телефон и т. Д. Информация ПЛЮС 1 «Адрес». Поэтому, когда семейство создается, модифицируется или удаляется с помощью триггера, я копирую содержимое таблицы семейства в его таблицу AUDIT Family_Audit. Точно так же, когда вносится изменение в таблицу «Контакт», я копирую его в таблицу «Contact_Audit». То же самое для адреса.

Таблица изменений: Если у меня уже есть таблицы аудита для каждой из таблиц объектов, для которых требуется «аудит», то какой смысл иметь таблицу изменений?

Учитывая это, я подумал, имеет ли для меня смысл использовать приведенные выше "шаблонные" столбцы.

Есть комментарии?

Более важно, какие столбцы шаблонов вы добавляете (почти) в каждую таблицу? почему?

Answer 1

Я стараюсь избегать «шаблонных столбцов».

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

Единственное, что близко к «шаблону» - это суррогатный первичный ключ (называемый идентификатором).

В большинстве случаев «шаблон» - история изменений -это даже не проблема, потому что я пытаюсь создавать проекты, в которых сохраняется история.Я стараюсь сократить количество случаев ОБНОВЛЕНИЯ до минимально возможного.

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

Я больше не вижу никаких значений в «шаблонных столбцах»

---

как происходит сохранение таблицыID строки "в справке журнала, если фактическое содержимое (в других столбцах) НЕ сохранено?

Что?Предыдущее значение строки может быть сохранено .В этом-то и дело.У вас есть несколько способов сохранения истории.

1. Разделение таблицы истории с предыдущими значениями.

2. «Флаг» - который создаетключ из двух частей - с настройкой «текущий» или «история».

3. Возможно использование пары дат «включено» и «неактивно».

Есть и другие техники.Прочитайте об алгоритмах медленно меняющегося измерения (SCD).

Каждый из этих методов имеет уникальные требования;это шаблоны дизайна, а не шаблон.

Answer 2

Вы правы, что эти столбцы логически избыточны при наличии полной таблицы аудита.

Преимущество сохранения любого из них возникнет, если вам потребуется простой доступ на основе индекса к таким запросам, как:

• Перечислите записи, созданные в определенном диапазоне дат (хотя на этот вопрос все еще можно было бы легко ответить из таблицы аудита).
• Список записей, которые последний раз обновлял конкретный человек (оптимизировать такой запрос проще).
• Показать последние обновленные 100 записей (опять же, не так просто оптимизировать в таблице аудита).

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