Formas de implementar versiones de datos en PostreSQL

Question

¿Puede compartir sus ideas sobre cómo implementar versiones de datos en PostgreSQL? (He hecho una pregunta similar con respecto a Cassandra y MongoDB. Si tiene alguna idea de qué db es mejor, comparta)

Supongamos que necesito versionar registros en una libreta de direcciones simple. Los registros de la libreta de direcciones se almacenan en una tabla sin relaciones por simplicidad. Espero que la historia:

• se utiliza con poca frecuencia
• serán utilizados a la vez para presentarlo en forma de "máquina del tiempo"
• no habrá más versiones que pocos cientos a unos registro único
• el historial no caducará.

estoy considerando los siguientes enfoques:

• Crear una nueva tabla de objetos para almacenar la historia de los registros con una copia del esquema de la tabla de direcciones y agregar marca de tiempo y la clave externa para hacer frente a mesa de libros.

• crear una especie de esquema menos tabla para almacenar los cambios para hacer frente a los registros de libros. Dicha tabla consistiría en: AddressBookId, TimeStamp, FieldName, Value. De esta manera, solo almacenaría cambios en los registros y no tendría que mantener la tabla de historial y la libreta de direcciones en sincronización.

• Crear una tabla para almacenar seralized (JSON) registros de la libreta de direcciones o cambios para hacer frente a los registros de libros. Tal tabla se vería de la siguiente manera: AddressBookId, TimeStamp, Object (varchar). De nuevo, este es el esquema menos, así que no tendría que mantener sincronizada la tabla de historial con la tabla de la libreta de direcciones. (This is modelled after Simple Document Versioning with CouchDB)

Answer 1

Hago algo así como su segundo enfoque: tener la tabla con el conjunto de trabajo actual y un historial con los cambios (marca de tiempo, record_id, property_id, property_value). Esto incluye la creación de registros. Una tercera tabla describe las propiedades (id, property_name, property_type), que ayudan a la conversión de datos más arriba en la aplicación. Por lo tanto, también puede rastrear muy fácilmente los cambios de propiedades individuales.

En lugar de una marca de tiempo también podría tener un int-like, que se incrementa para cada cambio por record_id, por lo que tiene una versión .

Answer 2

Usted podría tener start_date y end_date.

Cuando end_date es NULL, `s del registro real.

Answer 3

estoy de versiones de datos glosario, y mi enfoque fue muy exitoso para mis necesidades. Básicamente, para los registros que necesita versionar, divide el campo en campos persistentes y campos dependientes de la versión, creando así dos tablas. Algunos de los primeros conjuntos también deberían ser la clave única para la primera mesa.

Dirección
Identificación [pk]
nombre completo [uk]
cumpleaños [uk]

Versión
Identificación [pk]
address_id [uk]
marca de tiempo [uk]
dirección

De esta manera, obtienes una dirección de temas determinada por nombre completo y fecha de nacimiento (no debe cambiar por versiones) y un registro versionado que contiene direcciones. address_id debe estar relacionado con Address: id a través de una clave externa. Con cada entrada en la tabla de versiones, obtendrá una nueva versión para el asunto Dirección: id = id_dirección con una marca de tiempo específica, de forma que pueda tener una referencia de historial.