Регистрируем ли мы дублирующиеся данные в таблицах или продолжаем объединяться во всех будущих чтениях?

Question

Скажите таблицу активности пользователя. Как минимум вам понадобятся такие вещи, как user_id, datetime, activity_id, object_id и т. Д. Я могу объединиться с таблицей объектов, чтобы найти владельца объекта. Я могу объединиться с таблицей действий, чтобы найти группу действий, тип и т. Д.

ИЛИ

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

Если я дублирую данные, дублирую ли я их с помощью FK или автономно?

Answer 1

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

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

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

Но всегда применяйте к ним индексы и регулярно очищайте их;в противном случае превращайтесь в монстров.

Альтернативой файлам журнала являются таблицы истории.Вместо того, чтобы регистрировать файл для действий, он реализуется по мере необходимости.Для каждой таблицы, для которой должен быть сохранен Аудит изменений, реализуется «копия» таблицы.Это сохраняет предыдущее изображение строк, которые были изменены.DDL в точности совпадает с исходной таблицей, плюс один элемент: для PK добавлен столбец TIMESTAMP или DATETIME.Там также это явное требование, и было бы неправильно классифицировать эти таблицы как дубликаты или "ненормализованные".

Таблицы истории превосходят файлы журнала, потому что они хранят только строки, которые были изменены;тогда как файлы журнала хранят неизменяемые данные повторно.Результирующие объемы хранимых данных весьма различны.

▶ Пример таблиц истории ◀

Answer 2

То, о чем вы говорите, называется нормализация базы данных (или, в вашем случае ненормализация ).

Поскольку реляционная база данных в значительной степени предназначена для выполненияобъединений, как правило, ОЧЕНЬ мало причин отменять нормализацию и хранить дубликаты данных в одной большой широкой таблице (есть некоторые крайние случаи и компромиссы, но в используемом вами примере они действительно не применяются, поэтому я рекомендую придерживаться 3-подход таблицы, которую вы перечислили (активность, user_activity, объект).