mantener la historia en una base de datos

Question

Estoy diseñando esta base de datos que debe mantener un historial del salario de los empleados y los movimientos dentro de la organización. Básicamente, mi diseño tiene 3 tablas (es decir, hay más tablas, pero para esta pregunta mencionaré 3, así que tengan paciencia). Tabla de empleados (que contiene el sueldo más reciente, datos de posición, etc.), tabla de SalarioHistory (salario, fecha, razón, etc.) y MovementHistory (Título, Departamento, comentarios). Usaré Linq en Sql, entonces lo que estaba pensando es que cada vez que se actualicen los datos de los empleados, los valores anteriores se copiarán en sus respectivas tablas de historial. ¿Es este un buen enfoque? ¿Debo hacerlo usando Linq to SQL o disparadores? Gracias por cualquier ayuda, sugerencia o idea.

Answer 1

Eche un vistazo a http://www.simple-talk.com/sql/database-administration/database-design-a-point-in-time-architecture.

Básicamente, el artículo sugiere que tiene las siguientes columnas en las tablas que necesita para realizar un seguimiento de la historia de -

* DateCreated – the actual date on which the given row was inserted. 
* DateEffective – the date on which the given row became effective. 
* DateEnd – the date on which the given row ceased to be effective. 
* DateReplaced – the date on which the given row was replaced by another row. 
* OperatorCode – the unique identifier of the person (or system) that created the row. 

DateEffective y DateEnd juntos le dirá el tiempo durante el cual la fila era válida (o el tiempo para lo cual un empleado estaba en un departamento, o el tiempo por el cual ganó un salario particular).

Answer 2

Es una buena idea mantener esa lógica interna en la base de datos: eso es básicamente por qué existen los activadores. Lo digo con cuidado, sin embargo, ya que hay muchas razones para mantenerlo externo. Muchas veces, especialmente con una tecnología tan fácil como LINQ-to-SQL, es más fácil escribir el código externamente. En mi experiencia, más personas podrían escribir esa lógica en C#/LINQ que podría hacerlo correctamente usando un disparador.

Los disparadores son rápidos, ¡están compilados! Sin embargo, son muy fáciles de utilizar mal y hacen que su lógica sea demasiado compleja en un grado tal que el rendimiento puede degradarse rápidamente. Teniendo en cuenta lo simple que es su caso de uso, Optaría por utilizar los factores desencadenantes, pero ese soy yo personalmente.

Answer 3

Los desencadenantes probablemente serán más rápidos, y no requieren un "intermediario" para realizar el trabajo, eliminando al menos una posibilidad de errores.

Dependiendo de su base de datos de elección, puede simplemente usar una tabla y habilitar los OID en ella, y agregar dos columnas más, "marcar" y "anterior". Nunca actualice esta tabla, solo inserte. Agregue un desencadenador para que cuando se agregue una fila para el empleado #id, establezca todos los registros con el empleado #id para tener un indicador de "anterior" y establezca el nuevo valor "anterior" de filas en la fila anterior.

Answer 4

Los activadores hacen que su front-end sea más fácil de migrar a otra cosa y mantendrán la base de datos constante independientemente de cómo se inserten/actualicen/eliminen los datos.

Además, en su caso yo escribiría los salarios directamente en el historial salarial: según su descripción, no vería una razón por la que deba seguir el camino mediante un activador de actualización en la tabla de empleados.

Answer 5

Creo que esto pertenece a la base de datos por dos razones.

Primero, los niveles intermedios van y vienen, pero las bases de datos son para siempre. Este año Java EJB, el próximo año .NET, el año después de eso, algo más. Los datos permanecen, en mi experiencia.

En segundo lugar, si la base de datos se comparte en absoluto, no debería tener que depender de cada aplicación que la usa para saber cómo mantener su integridad de datos. Consideraría esto como un ejemplo de encapsulación de la base de datos. ¿Por qué forzar el conocimiento y el mantenimiento de la historia en cada cliente?