Лучшие практики для хранения метаданных записей

Какова наилучшая практика для хранения метаданных отдельных записей в базе данных?

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

Храните метаданные прямо в таблицах.

Плюсы:
- Метаданные напрямую связаны с записями
- Для получения метаданных не требуется никаких объединений
Минусы:
- Требуется много повторяющихся столбцов (если не используется наследование)
- Метаданные и бизнес-данные не разделены
Создайте общую таблицу метаданных с помощью программных внешних клавиш, чтобы связать данные с правильными таблицами и записями.

Плюсы:
- Нет дублирования столбцов
- Метаданные отделены от бизнес-данных
Минусы:
- Нет прямых связей между метаданными и данными (FK не могут быть использованы)
- Соединения требуют дополнительного условия
Создайте отдельные таблицы метаданных для каждой таблицы, требующей метаданных.

Плюсы:
- Метаданные напрямую связаны с записями
- Метаданные отделены от бизнес-данных
Минусы:
- Требуется много дополнительных таблиц
- Требуется много повторяющихся столбцов (если не используется наследование)

Есть ли больше вариантов, плюсов или минусов, чем те, которые я упомянул здесь? И какова лучшая практика для хранения этих метаданных?

postgresql database-design metadata

— Тиддо
источник

О каких метаданных мы говорим? Может быть, использование hstoreили JSONстолбца может решить вашу проблему?

— a_horse_with_no_name

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

— Тиддо

Тогда я не вижу причин не добавлять эти три столбца в базовую таблицу.

— a_horse_with_no_name

Столбцы, о которых вы говорите, занимают 20 байтов (если выровнены без заполнения):

время создания, время обновления и источник создания

метка времени .. метка времени 8 байтов
..
целое число 8 байтов .. 4 байта

Заголовок кортежа и указатель элемента для отдельной строки в отдельной таблице занимали бы 23 + 1 + 4 = 28 байт плюс 20 байтов фактических данных плюс 4 байта заполнения в конце. Делает 52 байта на строку . Узнайте больше здесь:

Настройка PostgreSQL для производительности чтения

Относительно хранения вам нечего получить. Что касается производительности, вы вряд ли что-то потеряете, имея всего 16 - 24 байта на строку.

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

Также легче написать, TRIGGER ON INSERT OR UPDATEчтобы держать их в курсе.

Короче говоря: сильный голос за ваш вариант 1 .

Куда я бы пошел для варианта 3 :
если метаданные часто обновляются, а в основной строке нет. Тогда может потребоваться сохранить отдельную таблицу 1: 1, чтобы удешевить ОБНОВЛЕНИЯ и уменьшить объем на основной таблице - или даже перейти к варианту 2.

Куда я пошел бы для варианта 2 :
Если набор столбцов метаданных является очень повторяющимся. Вы можете иметь столбец FK для набора метаданных в основной таблице (таблицах). Не экономит много для трех маленьких столбцов, как в вашем примере.

— Эрвин Брандштеттер
источник

Как насчет решения этой проблемы с помощью наследования таблиц, есть ли замечательные недостатки по сравнению с использованием столбцов метаданных непосредственно в таблице? Однако, если я правильно понимаю, наследование таблиц postgres не соответствует стандарту SQL, не так ли?

— Devrys

@devrys: Наследование имеет некоторые ограничения в Postgres. Более важно: я не понимаю, как наследование может решить сохранение дополнительных столбцов в строке. это будет вариант, если у вас есть несколько строк с метаданными, а другие - без метаданных. Но я бы не стал использовать это для этого.

— Эрвин Брандштеттер,