Meilleure pratique pour le stockage des métadonnées d'enregistrement

Quelle est la meilleure pratique pour stocker des métadonnées d'enregistrements individuels dans une base de données?

J'ai besoin de stocker des métadonnées communes telles que l'heure de création et l'heure de la dernière mise à jour de nombreuses tables dans ma base de données. J'ai trouvé quelques solutions différentes:

Stockez les métadonnées directement dans les tableaux.

Avantages:
- Les métadonnées sont directement liées aux enregistrements
- Aucune jointure n'est requise pour récupérer les métadonnées
Les inconvénients:
- Un grand nombre de colonnes en double sont requises (sauf si l'héritage est utilisé)
- Les métadonnées et les données d'entreprise ne sont pas séparées
Créez une table de métadonnées générale avec et utilisez des clés étrangères programmables pour lier les données aux tables et enregistrements appropriés.

Avantages:
- Pas de duplication des colonnes
- Les métadonnées sont séparées des données d'entreprise
Les inconvénients:
- Aucun lien direct entre les métadonnées et les données (les FK ne peuvent pas être utilisés)
- Les jointures nécessitent une condition supplémentaire
Créez des tables de métadonnées individuelles pour chaque table nécessitant des métadonnées.

Avantages:
- Les métadonnées sont directement liées aux enregistrements
- Les métadonnées sont séparées des données d'entreprise
Les inconvénients:
- Beaucoup de tables supplémentaires sont nécessaires
- Un grand nombre de colonnes en double sont requises (sauf si l'héritage est utilisé)

Y a-t-il plus d'options, d'avantages ou d'inconvénients que ceux que j'ai mentionnés ici? Et quelle est la meilleure pratique pour stocker ces métadonnées?

postgresql database-design metadata

— Tiddo
source

De quel type de métadonnées parlons-nous? Peut-être que l'utilisation d'une colonne hstoreou JSONpourrait résoudre votre problème?

— a_horse_with_no_name

@a_horse_with_no_name - Pour le moment, je n'ai besoin que du temps de création, du temps de mise à jour et de la source de création. Les champs sont fixes, donc je n'ai pas besoin de valeur-clé comme le stockage. Je m'inquiète seulement de l'endroit où je dois stocker les données.

— Tiddo

Ensuite, je ne vois aucune raison de ne pas ajouter ces trois colonnes à la table de base.

— a_horse_with_no_name

Les colonnes dont vous parlez occupent 20 octets (si alignées sans remplissage):

heure de création, heure de mise à jour et source de création

horodatage .. 8 octets
horodatage .. 8 octets
entier .. 4 octets

L'en-tête de tuple et le pointeur d'élément pour une ligne distincte dans une table distincte occuperaient à eux seuls 23 + 1 + 4 = 28 octets plus les 20 octets de données réelles, plus 4 octets de remplissage à la fin. Donne 52 octets par ligne . En savoir plus ici:

Configuration de PostgreSQL pour les performances de lecture

Concernant le stockage, vous n'avez rien à gagner. En ce qui concerne les performances, vous ne perdez pratiquement rien avec seulement 16 à 24 octets de plus par ligne.

Les colonnes appartiennent également directement à la ligne, il est donc logique de les garder ensemble. Je prends l'habitude d'ajouter exactement de telles colonnes (plus une source distincte pour la dernière mise à jour) à toutes les tables pertinentes.

Il est également plus facile d'écrire un TRIGGER ON INSERT OR UPDATEpour les garder à jour.

Pour faire court: un vote fort pour votre option 1 .

Où j'irais pour l' option 3 :
si les métadonnées sont mises à jour souvent, alors que la ligne principale ne l'est pas. Ensuite, il pourrait être avantageux de conserver une table 1: 1 distincte pour réduire les mises à jour et réduire les ballonnements sur la table principale - ou même opter pour l'option 2.

Où irais-je pour l' option 2 :
si l'ensemble des colonnes de métadonnées est hautement répétitif. Vous pouvez avoir une colonne FK pour l'ensemble des métadonnées dans les tables principales. N'économise pas beaucoup pour trois petites colonnes comme dans votre exemple.

— Erwin Brandstetter
source

Que diriez-vous de résoudre ce problème avec l'héritage de table, y a-t-il des inconvénients remarquables par rapport à l'utilisation de colonnes de métadonnées directement dans la table? Cependant, si je comprends bien, l'héritage de table de postgres n'est pas conforme au standard SQL, n'est-ce pas?

— devrys

@devrys: L' héritage a quelques limitations dans Postgres Plus important encore: je ne vois pas comment l'héritage pourrait résoudre l' enregistrement de quelques colonnes supplémentaires par ligne. ce serait une option si vous avez des lignes avec et d'autres lignes sans métadonnées. Mais je ne l' utiliserais pas pour ça.

— Erwin Brandstetter