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

10

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

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

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

    Плюсы:

    • Метаданные напрямую связаны с записями
    • Для получения метаданных не требуется никаких объединений

    Минусы:

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

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

    Плюсы:

    • Нет дублирования столбцов
    • Метаданные отделены от бизнес-данных

    Минусы:

    • Нет прямых связей между метаданными и данными (FK не могут быть использованы)
    • Соединения требуют дополнительного условия

  3. Создайте отдельные таблицы метаданных для каждой таблицы, требующей метаданных.

    Плюсы:

    • Метаданные напрямую связаны с записями
    • Метаданные отделены от бизнес-данных

    Минусы:

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

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

postgresql database-design metadata Тиддо
источник
О каких метаданных мы говорим? Может быть, использование hstoreили JSONстолбца может решить вашу проблему?
a_horse_with_no_name
@a_horse_with_no_name - сейчас мне нужно только время создания, время обновления и источник создания. Поля являются фиксированными, поэтому мне не нужно ключевое значение, как хранилище. Я беспокоюсь только о том, где я должен хранить данные.
Тиддо
1
Тогда я не вижу причин не добавлять эти три столбца в базовую таблицу.
a_horse_with_no_name

Ответы:

7

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

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

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

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

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

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

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

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

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

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

Эрвин Брандштеттер
источник
Как насчет решения этой проблемы с помощью наследования таблиц, есть ли замечательные недостатки по сравнению с использованием столбцов метаданных непосредственно в таблице? Однако, если я правильно понимаю, наследование таблиц postgres не соответствует стандарту SQL, не так ли?
Devrys
1
@devrys: Наследование имеет некоторые ограничения в Postgres. Более важно: я не понимаю, как наследование может решить сохранение дополнительных столбцов в строке. это будет вариант, если у вас есть несколько строк с метаданными, а другие - без метаданных. Но я бы не стал использовать это для этого.
Эрвин Брандштеттер,