2010-03-29 20 views
19

Tengo que crear un código en PHP que me permita mantener el historial de actualizaciones de registros en la base de datos MySQL para poder encontrar por fecha una revisión anterior.¿Cómo mantener el historial de actualizaciones de registros en MySQL?

Aquí está el ejemplo de lo que podía comprender quiero achive: http://en.wikipedia.org/w/index.php?title=Tunisia&action=history

Los datos son en su mayoría los números que tenemos registrada de la empresa para generar informes y extraer índices.

Planeo usar codeigniter por su simplicidad y estoy buscando ideas sobre un marco o un proyecto de código abierto que use el mismo enfoque para mantener el historial de modificaciones en la base de datos.

Respuesta

1

Eso no está registrando las actualizaciones SQL actuales. Está registrando las actualizaciones de los datos. De hecho, almacenará todas las revisiones de la página y solo proporcionará la última por defecto. El código SQL que se utilizó no se almacenó.

Por lo tanto, tendrá que adoptar un enfoque similar. Cada vez que los datos cambian, deberá averiguar cómo han cambiado los datos y almacenar estos datos 'parche'. Probablemente será mejor almacenar la última versión, en lugar de tener que trabajar en todos los parches para llegar a ella. Esto significa que usted será capaz de ver algo como

! created file 
* added data to cell D4 'product descript' D5 'set of pens' E5 '£5.99' 
* added data to cell D6 'toaster' E5 '£10' 
& changed data in cell D4 'Product Description' 

Cada uno de estos cambios tendrían que ser almacenado con una marca de tiempo o cuando eran hecho. También necesitará elaborar su propio esquema para almacenar los cambios en los datos.

Otra solución más simple sería usar un motor de wiki, que proporciona todas las funcionalidades que desea, si está dispuesto a trabajar en una página web. Es posible que deba dedicar algún tiempo para que funcione mejor para sus necesidades, permitiendo que las personas lo editen desde una vista más acabada, en lugar de una wiki en bruto.

2

Debe usar una capa adicional entre su aplicación y el db. Puede hacer que sea muy simple por su cuenta (en lugar de llamar directamente al mysql_query llame a una función creada por usted que lo envuelve y que rastrea las actualizaciones), o utilice algún ORM existente. En pseudo-código

my_mysql_query($query){ 
    if($query is an update){ 
     //Log stuff before query 
    } 
    $r = mysql_query($query); 

    if ($r && $query is an update){ 
     //Log stuff after query 
    } 
    return $r; 
} 

Y luego, en su solicitud de llamada que my_mysql_query en lugar de mysql_query. Puede verificar si la tabla es la que desea rastrear y puede copiar la fila en una copia de la tabla original.

Si usa Doctrine ORM, puede usar su Event Listeners para obtener lo que desea.

7

Una forma simple de mantener el historial de versiones es crear básicamente una tabla idéntica (por ejemplo, con _version sufijo). Ambas tablas tendrían un campo de versión, que para la tabla principal aumentará para cada actualización que haga. La tabla de versión tendría una clave primaria compuesta en (id, version).

Siempre que realice una actualización en la tabla real, también INSERTE una nueva fila en la tabla de versión con datos duplicados. Siempre que desee encontrar el historial de versiones, todo lo que necesita hacer es algo como SELECT * FROM content_version WHERE id = CONTENT_ID ORDER BY version.

Si usa algo como Doctrine ORM, tiene un comportamiento que lo hace automáticamente a través de los detectores de eventos.Puedes consultarlo aquí: http://www.doctrine-project.org/documentation/manual/1_2/en/behaviors#core-behaviors:versionable

+5

¿por qué no seguir así? 'Main table' contiene solo' id' y 'version_id'' version' tabla contiene todos los datos? – Shaheer

+0

Gracias @Shaheer voy a probar este. – Eric

+0

@Shaheer porque la mayoría de las consultas están en contra de los datos actuales, por lo que dividir el historial en una tabla separada garantiza que esas consultas no tengan la penalidad de rendimiento de tener la tabla * n * veces más grande. La magnitud * n * dependerá de la frecuencia con la que se actualicen los registros. –

1

Si entiendo correctamente, estás guardando solo un "número" en una tabla específica, y quieres el historial de revisión de ese número?

Yo diría: escriba su modelo de datos para que contenga un historial de ese número. Por lo tanto, no solo registra el último valor de ese número, sino que también conserva los valores anteriores.

Una forma sencilla de hacer esto es tener una tabla con los siguientes campos:

  • Identificación
  • CompanyID
  • número
  • marca de tiempo

Si usted quiere saber el número actual, solo haga

SELECT * FROM table WHERE companyId = X ORDER BY timestamp DESC LIMIT 1 

Si quieres ver todas las revisiones acaba de hacer:

SELECT * FROM table WHERE companyId = X 
+0

Es un tablero que estoy tratando de migrar desde un simple archivo de Excel. Como no estoy familiarizado con la forma ORM, prefiero escribir mi propio código. – Proxium

+0

Que puede ser algo bueno :) –

+1

SELECCIONAR * FROM tabla WHERE companyId = X ORDER BY timestamp DESC LIMIT 1 – DarkSide

15

La solución más fácil (en función de sus necesidades específicas), probablemente sería añadir una en la actualización/insertar/borrar gatillo a su mesa, por lo que puede realizar un registro adicional cuando los datos se insertan/actualizan/eliminan. De esta forma, incluso las intervenciones manuales en el db se cubrirán ...

Compruebe http://dev.mysql.com/doc/refman/5.1/en/triggers.html para obtener más información.

6

Existe un marco de código abierto (licencia MIT) para crear aplicaciones web basadas en bases de datos CRM y ERP. Puede descargar EPESI de http://epe.si/ disponible también en SourceFroge: http://sourceforge.net/projects/epesi/

de EPESI CRUD motor - el navegador Registro - tiene una historia registro muy eficiente, así como otras características como el sistema de permiso por adelantado (hasta un campo nivel) y mucho más.

Un único conjunto de registros almacena datos en hasta 10 tablas y es independiente de la base de datos (utiliza PHPAdoDB). Una tabla llamada recordset_data almacena los datos "en bruto" y el historial de cambios se almacena en 2 tablas adicionales: recordset_edit_history y recordset_edit_history_data.edit_history

de registro tiene la siguiente estructura:

  • ID (clave principal de esta tabla, índice)
  • Editado el (fecha y hora: 2008-05-14 15:18:15)
  • Edited por: (ID de usuario) edit_history_data

de registro tiene la siguiente estructura:

  • edit_id = Identificación de editar la historia
  • campo = el nombre del campo que se ha cambiado
  • old_value = valor del campo que ha cambiado.

Es un motor muy rápido y eficiente y almacena los cambios no en el registro sino en un solo nivel de campo.

Cuestiones relacionadas