PostgreSQL bytea Clé primaire

Question

J'ai une table dans ma base de données qui stocke les journaux. Les fichiers journaux sont horodatées avec précision à la seconde et de stocker les valeurs des différents capteurs et leur source:

log_id, log_date, primary_system_source, sub_system_source, values 

Où log_id, primary_source et sub_source sont des entiers et des valeurs est un tableau d'octets de longueur variable (type de données: bytea).

Dans la plupart des cas, une combinaison des champs log_id, log_date, primary_system_source et sub_system_source suffirait comme clé primaire. Malheureusement, en raison de la résolution de l'horodatage dans le système de journalisation dans certaines lignes, le seul facteur qui différencie les rangées est que les valeurs des capteurs sont également ajoutées à la clé primaire.

Il semble que j'ai le choix entre l'absence de clé primaire (mauvaise?) Et l'inclusion du champ de valeurs dans la clé primaire. Je suis préoccupé par le second choix car je comprends qu'il pourrait être sérieusement préjudiciable à la performance (la table aura des centaines de millions de lignes).

Des indices quant à la meilleure solution?

Answer 1

C'est un problème difficile car votre rangée entière fonctionne comme votre clé primaire dans l'exemple que vous venez de présenter. Étant donné que votre journal horodatage sans précision absolue, je dirais que vos journaux eux-mêmes ne peuvent pas contenir des valeurs uniques (deux lectures sensorielles similaires dans la même période). Si cela est vrai, vous n'avez aucun moyen d'identifier vos données de manière unique et vous ne pouvez donc pas lui imposer une contrainte unique.

Je vous recommande simplement d'ajouter un champ SERIAL PK pour les liens vers d'autres relations et ne vous souciez pas de l'unicité de vos entrées puisque vous ne pouvez pas raisonnablement l'appliquer de toute façon. Vous pouvez identifier les entrées de journal dupliquées si vous avez un plus grand nombre d'entrées dans une période de temps que prévu. Je ne suis pas sûr des implications sur les performances, mais exécuter SELECT DISTINCT peut être plus prudent que d'essayer d'imposer l'unicité.