none
Cual es la mejor forma de manejar los Logs de una aplicación para mantener cada registro RRS feed

  • Pregunta

  • Hola a todos

    1- Tengo una aplicación en la que necesito mantener cada registro de mis tablas, por lo que si un usuario hace un update de una tabla es también necesario mantener los registros viejos, ejemplo si un usuario modifica su Email, Nombre, Telefono o lo que sea de la tabla Usuario hay que mantener eso.
    Lo que tengo en mente es replicar las tabls en una base de datos de Logs y allí almacenar cada vez que se inserte o modifique, pero quería saber si existe una mejor forma o una especie de stanrdards ya establecido para estos casos.

    2- Otra de las cosas que tengo que guardar por procesos de Auditoria o Inteligencia de Negocio, es cada vez que se hace una consulta en una tabla, los parametros de entradas y el número de registros de retorno, esto para todos los métodos. Supongamos que tengo este método:

    List<Entity> Test(string param1, int param2, string param3);

    Debo guardar los parametros "param1, param2 y param3" y la cantidad de registros de retorno, el asunto es que lo necesito hacer para cada método, los cuales pueden tener diferentes firmas y también guardarlo de manera organizada para que luego se puedan tomar decisiones de negocios analizando las veces que se ejecuta el método, cantidad de registros de retorno, etc...

    Alguien que maneje grandes aplicaciones con bastante data, que me pueda orientar.

    Saludos
    domingo, 8 de octubre de 2017 19:34

Respuestas

  •  sabes si funciona para alguna versión especifica de SQL o cualquiera?

    Antiguamente (2008) requería una edición Enterprise, pero en sucesivas versiones las varias características de SQL Server que al principio solo estaban en la Enterprise se han ido extendiendo a otras ediciones. No sé cómo ha quedado el CDC, pero merece la pena consultarlo por que es posible que en las últimas versiones esté disponible en ediciones menores. Concretamente, en el 2016 SP1 está también disponible en la edición Standard.

    En cuanto al punto 2, si lo único que necesitas es la estructura de tabla, yo recomendaría crear una tabla sencillita con cosas como el nombre de método, fecha y hora, y número de registros devueltos, y luego añadir un campo XML llamado Parámetros y ahí encapsular los valores de los parámetros que como sabemos son diferentes según el método.

    lunes, 9 de octubre de 2017 6:38

Todas las respuestas

  • Para el punto 1, existe una característica en SQL que sirve precisamente para eso. Se llama "Change Data Capture" (CDC - Captura de Cambio de Datos). Una vez que habilitas el CDC, te crea internamente en la base de datos unas tablas de sistema que van salvando automáticamente esos registros "históricos" de cambios. Y luego también te crea unas funciones con nombres tales como cdc.fn_cdc_get_net_changes_miTabla, que te permiten consultar esos cambios aplicando criterios tales como "desde" y "hasta".

    Para el punto 2, me temo que no puedes hacerlo desde el SQL Server, porque esos métodos que tienes son invisible para el servidor, que solo recibe la sentencia SQL y no sabe qué parámetros tenía el método ni cuál era el método. Así que esa auditoría tendrás que hacerla desde el código cliente. Tendrás que preguntarlo en el foro que corresponda a la tecnología que uses, posiblemente en el foro de Entity Framework, o si acaso en el de ADO.NET o incluso el de C#, pero no en este foro de SQL Server.

    domingo, 8 de octubre de 2017 19:55
  • Para el punto 1, existe una característica en SQL que sirve precisamente para eso. Se llama "Change Data Capture" (CDC - Captura de Cambio de Datos). Una vez que habilitas el CDC, te crea internamente en la base de datos unas tablas de sistema que van salvando automáticamente esos registros "históricos" de cambios. Y luego también te crea unas funciones con nombres tales como cdc.fn_cdc_get_net_changes_miTabla, que te permiten consultar esos cambios aplicando criterios tales como "desde" y "hasta".

    Para el punto 2, me temo que no puedes hacerlo desde el SQL Server, porque esos métodos que tienes son invisible para el servidor, que solo recibe la sentencia SQL y no sabe qué parámetros tenía el método ni cuál era el método. Así que esa auditoría tendrás que hacerla desde el código cliente. Tendrás que preguntarlo en el foro que corresponda a la tecnología que uses, posiblemente en el foro de Entity Framework, o si acaso en el de ADO.NET o incluso el de C#, pero no en este foro de SQL Server.

    Hola como estás

    Para el punto uno voy averiguar al rspecto, sabes si funciona para alguna versión especifica de SQL o cualquiera? Buscaba algo así.

    Para el punto 2, cundo mencionaba los metodos hacia referencia a crear una estructura de data que sea totalmente dinámica o ajustable a mis necesidades. No hacerlo desde .NET, obviamente tengo que crear mis tablas desde SQL y desde .NET solo invocar los SP.

    Saludos

    lunes, 9 de octubre de 2017 1:47
  •  sabes si funciona para alguna versión especifica de SQL o cualquiera?

    Antiguamente (2008) requería una edición Enterprise, pero en sucesivas versiones las varias características de SQL Server que al principio solo estaban en la Enterprise se han ido extendiendo a otras ediciones. No sé cómo ha quedado el CDC, pero merece la pena consultarlo por que es posible que en las últimas versiones esté disponible en ediciones menores. Concretamente, en el 2016 SP1 está también disponible en la edición Standard.

    En cuanto al punto 2, si lo único que necesitas es la estructura de tabla, yo recomendaría crear una tabla sencillita con cosas como el nombre de método, fecha y hora, y número de registros devueltos, y luego añadir un campo XML llamado Parámetros y ahí encapsular los valores de los parámetros que como sabemos son diferentes según el método.

    lunes, 9 de octubre de 2017 6:38