2011-12-15 10 views
7

Quiero almacenar una publicación de blog en una base de datos. Pensé que sería bueno tener diferentes versiones de esos datos, al igual que el control de versiones para los archivos de texto.¿Cuáles son las formas estándar/recomendadas para almacenar datos de base de datos controlados por versión?

Entonces, me imagino que funciona como una fila en una tabla, que tenía control de versión. Entonces, por ejemplo, podría recuperar la última versión de esa fila o una versión anterior. Incluso podrías ramificar desde esa fila.

¿Existe algo como esto?

Posiblemente la información útil: Actualmente estoy usando Python, Django & MySQL. Estoy experimentando con MongoDB

Edit for clarity/more context: Estoy buscando una solución más adaptada al "control de versiones" de filas que de bases de datos; No estoy tan interesado en la ramificación de bases de datos completas. Por ejemplo, podría consultar el contenido de la publicación de blog al 1/1/2011 y al 1/1/2010 (sin cambiar las bases de datos).

+0

¿Ha considerado utilizar un sistema de control de versiones como git? Sería interesante ver los pros y los contras de tal solución. – milan

+0

@milan - ¿desde cuándo la base de datos de versiones de git ** graba **? –

+0

La pregunta no dice * ningún * registro de base de datos, dice publicaciones de blog, que en su mayoría son texto, ¿por qué no? – milan

Respuesta

2

En primer lugar, debo decir que esta es una pregunta interesante.

En mi trabajo, tengo que guardar versiones de varias entradas de usuario. La forma en que lo hago, y por supuesto no sé si es la manera correcta o no, es la siguiente:

Tengo una tabla master y una tabla revisions. Elegí estos 2 nombres solo por el ejemplo.

¿Qué maestro es almacena la siguiente información:

  • id (incremento automático)
  • version_id (int)

Lo revisions tienda es la siguiente:

  • Identificación
  • master_id
  • VERSION_ID
  • resto de los datos relevantes acerca de la entidad entrado (fechas, etc.)

lo que he logrado de esta manera es que me había conseguido un diámetro interior de, digamos un blog. Si alguien edita la publicación, la almacenaré en la tabla revisions. A través de los disparadores, estoy incrementando el version_id en la tabla revisions. Después de eso actualizo la tabla master con el último número version_id. De esa forma no tengo que realizar MAX() cuando quiero ver cuál es la última versión.

De esta forma obtuve un sistema de versión de la página web simple pero potente. Es fácil ver los cambios, y también es extremadamente rápido obtener datos si se abusan de algunas características geniales de MySQL (en mis tablas reales, estoy abusando de la clave primaria agrupada de InnoDB al máximo, por lo que el diseño db es ligeramente diferente que el Publiqué aquí).

3

El control de versiones es un tema complicado; hacerlo bien es realmente un desafío, que es esencialmente por qué incluso usando p. git puede ser difícil. No me gustaría escribir un sistema completo de control de versiones.

Para conocer los requisitos más simples, tenga en cuenta esta estructura, en pseudo-mongodb/JSON:

BlogPost { 
    "_id": ObjectId("..."), 
    "slug" : "how-to-version-my-posts", 
    "author" : "cammil", 
    "published" : date, 
    "lastModified" : date, 
    "publicVersion" : 32, 
    "draftVersion" : 34, 
    "teaserText" : "lorem ipsum dolor sit amet..." 
} 

BlogPostBody { 
    "_id" : ObjectId("..."), 
    "Version" : 32, 
    "Text" : "lorem ipsum dolor sit amet..." 
} 

Así que la idea aquí es almacenar cada versión por separado y un puntero a la versión pública actual y la versión actual de los editores , bloggers, etc.

Mi respuesta es un poco MongoDB céntrico (porque construí un motor de blog basado en MongoDB para uso doméstico), pero debería funcionar de manera similar para cualquier sistema de almacenamiento.

Ventajas:

  • No hay necesidad de hacer MAX consultas del número de versión, ya sea para cargos públicos o privados
  • no se correlaciona last edited a los números de versión, que podría no ser deseable
  • Permite el control de versiones, incluso si una determinada versión ya está publicada
  • Puede recuperar el avance sin tener que buscar el artículo completo

Desventajas:

  • copia todo el texto cada vez. No es una preocupación real para datos de texto, supongo (intente escribir 1GB ...). Sin embargo, será un problema para los sitios de blogs más grandes. Mitigación: Comprimir texto usando desinflar, compresión delta.
  • necesita actualizar dos objetos en la actualización
2

OffScale DataGrove que permite a la versión que toda DB.

Realiza un seguimiento de todos los cambios que suceden en la base de datos y puede etiquetar versiones y alternar entre ellas. DataGrove es único en el hecho de que versiona toda la base de datos: esquema y datos.

En su ejemplo, solo agregue la fila/datos que desea a la base de datos y etiquete una versión. Siempre podrás volver a esa versión e incluso partir de ella.

+1

Según su descripción, DataGrove parece estar más orientado hacia la bifurcación para bases de datos completas que para filas individuales. (Ver edición) – cammil

Cuestiones relacionadas