Façons de mettre en œuvre des données dans PostgreSQL versioning

Question

Pouvez-vous partager vos pensées comment voulez-vous mettre en œuvre des données dans PostgreSQL versioning. (Je l'ai posé la question similaire concernant Cassandra et MongoDB . Si vous avez des pensées qui db est meilleur pour cette part s'il vous plaît)

Supposons que je dois des documents de version dans un carnet d'adresses simple. dossiers du carnet d'adresses sont stockées dans une table sans relations pour la simplicité. Je pense que l'histoire:

• sera rarement utilisé
• sera utilisé à la fois pour le présenter de façon « time machine »
• il n'y aura pas plus de versions que quelques centaines à un seul enregistrement.
• l'histoire n'expirera.

J'envisage les approches suivantes:

• Créer une nouvelle table d'objets à l'histoire du magasin d'enregistrements avec une copie du schéma de table et l'horodatage addressbook ajouter et clé étrangère à la table du carnet d'adresses.

• Créer une sorte de schéma moins table pour stocker les modifications d'enregistrements du carnet d'adresses. Un tel tableau serait composé de: AddressBookId, TimeStamp, FieldName, valeur. De cette façon, je ne stocker que des changements aux dossiers et je ne pas avoir à garder la table d'historique et d'une table de carnet d'adresses dans la synchronisation.

• Créer une table pour stocker seralized (JSON) des dossiers de carnet d'adresses ou des changements aux dossiers du carnet d'adresses. Un tel tableau serait présente comme suit: AddressBookId, TimeStamp, objet (varchar). Encore une fois c'est schéma moins je ne voudrais pas garder la table d'historique avec table de carnet d'adresses dans la synchronisation. ( C'est calqués simple document avec Versioning CouchDB )

Answer 1

je faire quelque chose comme votre deuxième approche: avoir la table avec le jeu de travail réel et une histoire avec des changements (horodatage, record_id, property_id, property_value). Cela inclut la création d'enregistrements. Un troisième tableau décrit les propriétés (id, property_name, property_type), qui contribue à la conversion des données plus haut dans l'application. Ainsi, vous pouvez également suivre les changements très facilement des propriétés individuelles.

Au lieu d'un horodatage vous pouvez également avoir un int comme, Wich vous incrément pour chaque changement par record_id, de sorte que vous avez une réelle Version .

Answer 2

Vous pourriez avoir start_date et end_date.

Quand end_date est NULL, il s `l'enregistrement réel.

Answer 3

Je suis données glossaire des versions, et mon approche a été assez réussie pour mes besoins. En gros, pour les dossiers dont vous avez besoin versioning, vous divisez le fieldset dans les champs persistants et des champs dépendant de la version, créant ainsi deux tables. Une partie de la première série devrait également être la clé unique pour la première table.

Adresse id [pk]
fullname [uk]
anniversaire [uk]
Version id [pk]
ADDRESS_ID [uk]
timestamp [uk]
adresse

De cette façon, vous obtenez un sujet d'adresse déterminée par fullname et anniversaire (ne devrait pas changer par versioning) et les enregistrements contenant des adresses versionnés. ADDRESS_ID devrait être liée à Adresse: id par clé étrangère. Avec chaque entrée dans le tableau Version vous obtenez une nouvelle version pour le sujet. Adresse: id = ADDRESS_ID avec un horodatage spécifique, de quelle manière vous pouvez avoir une référence historique