Найкраща практика для зберігання метаданих записів

Яка найкраща практика зберігання метаданих окремих записів у базі даних?

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

1. Зберігайте метадані безпосередньо в таблицях.

   Плюси:

   • Метадані безпосередньо пов'язані із записами
   • Для отримання метаданих не потрібно ніяких приєднань

   Мінуси:

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

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

   Плюси:

   • Немає дублювання стовпців
   • Метадані відокремлені від бізнес-даних

   Мінуси:

   • Немає прямих зв’язків між метаданими та даними (FK не можна використовувати)
   • Приєднання вимагає додаткової умови

3. Створіть окремі таблиці метаданих для кожної таблиці, що вимагає метаданих.

   Плюси:

   • Метадані безпосередньо пов'язані із записами
   • Метадані відокремлені від бізнес-даних

   Мінуси:

   • Потрібно багато додаткових таблиць
   • Потрібно багато повторюваних стовпців (якщо не використовується спадщина)

Чи є більше варіантів, плюсів чи мінусів, ніж ті, про які я згадував тут? І яка найкраща практика зберігання цих метаданих?

Стовпці, про які ви говорите, займають 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 для набору метаданих у головній таблиці. Не економить багато для трьох невеликих стовпців, як у вашому прикладі.