Best practice per la memorizzazione di metadati dei record

Qual è la migliore pratica per la memorizzazione di metadati di singoli record in un database?

Devo memorizzare metadati comuni come l'ora di creazione e l'ora dell'ultimo aggiornamento per molte tabelle nel mio database. Ho trovato alcune soluzioni diverse:

1. Memorizza i metadati direttamente nelle tabelle.

   Professionisti:

   • I metadati sono direttamente collegati ai record
   • Non sono richiesti join per recuperare i metadati

   Contro:

   • Sono necessarie molte colonne duplicate (a meno che non venga utilizzata l'ereditarietà)
   • I metadati e i dati aziendali non sono separati

2. Creare una tabella di metadati generale con e utilizzare chiavi esterne soft per collegare i dati alle tabelle e ai record corretti.

   Professionisti:

   • Nessuna duplicazione di colonne
   • I metadati sono separati dai dati aziendali

   Contro:

   • Nessun collegamento diretto tra metadati e dati (gli FK non possono essere utilizzati)
   • I join richiedono una condizione aggiuntiva

3. Crea singole metadati per ogni tabella che richiede metadati.

   Professionisti:

   • I metadati sono direttamente collegati ai record
   • I metadati sono separati dai dati aziendali

   Contro:

   • Sono richiesti molti tavoli extra
   • Sono necessarie molte colonne duplicate (a meno che non venga utilizzata l'ereditarietà)

Ci sono più opzioni, vantaggi o svantaggi di quelli che ho menzionato qui? E qual è la migliore pratica per la memorizzazione di questi metadati?

Le colonne di cui stai parlando occupano 20 byte (se allineate senza riempimento):

tempo di creazione, tempo di aggiornamento e fonte di creazione

timestamp .. 8 byte
timestamp .. 8 byte
intero .. 4 byte

L'intestazione tupla e il puntatore elemento per una riga separata in una sola tabella separata occuperebbero 23 + 1 + 4 = 28 byte più i 20 byte di dati effettivi, più 4 byte di riempimento alla fine. Rende 52 byte per riga . Leggi di più qui:

• Configurazione di PostgreSQL per prestazioni di lettura

Per quanto riguarda lo spazio di archiviazione, non hai nulla da guadagnare. Per quanto riguarda le prestazioni, non si perde quasi nulla con solo 16-24 byte in più per riga.

Anche le colonne appartengono direttamente alla riga, quindi ha senso tenerle insieme. Ho l'abitudine di aggiungere esattamente tali colonne (più una fonte separata per l'ultimo aggiornamento) a tutte le tabelle pertinenti.

È anche più facile scrivere a TRIGGER ON INSERT OR UPDATEper mantenerli aggiornati.

Per farla breve: un voto forte per la tua opzione 1 .

Dove andrei per l' opzione 3 :
se i metadati vengono aggiornati spesso, mentre la riga principale non lo è. Quindi potrebbe essere utile mantenere una tabella 1: 1 separata per rendere gli AGGIORNAMENTI più economici e ridurre il rigonfiamento sulla tabella principale - o persino optare per l'opzione 2.

Dove andrei per l' opzione 2 :
se l'insieme di colonne di metadati è altamente ripetitivo. Potresti avere una colonna FK per l'insieme di metadati nelle tabelle principali. Non risparmia molto per tre piccole colonne come nel tuo esempio.