¿Es mejor iniciar sesión en el archivo o la base de datos?

Question

Todavía estamos usando ASP clásico antiguo y queremos iniciar sesión cada vez que un usuario hace algo en nuestra aplicación. Escribiremos una subrutina genérica para tomar en cuenta los detalles que queremos registrar.

¿Deberíamos registrar esto para decir un archivo txt usando FileSystemObject o registrarlo en una base de datos MSSQL?

Si la base de datos, ¿deberíamos agregar una nueva tabla a la única base de datos existente o deberíamos usar una base de datos separada?

Answer 1

Editar

En retrospectiva, una mejor respuesta es iniciar sesión en AMBOS sistema de archivos (primero, inmediatamente) y luego a una base de datos centralizada (incluso si está retrasada).

La razón detrás de escribir en el sistema de archivos es que si una dependencia de infraestructura externa como red, base de datos o problema de seguridad le impide escribir de forma remota, al menos tiene una recuperación si puede recuperar datos del disco duro del servidor web (algo parecido a una caja negra en la industria de las aerolíneas).

De hecho, los administradores de registro de la empresa como Splunk se puede configurar para raspar los archivos de registro del servidor local (por ejemplo, según lo escrito por log4net, la EntLib Logging Application Block, et al) y luego centralizar en una base de datos, donde los datos archivados pueden minado, graficado, mostrado en tableros, etc.

Pero desde una perspectiva operativa, donde es probable que tenga una granja de servidores web, y suponiendo que el sistema de archivos local y los mecanismos de registro de base de datos remotos funcionen, el caso de uso del 99% para tratar de encontrar algo en un archivo de registro seguirá siendo a través de la base de datos central (idealmente con un sistema frontal decente que le permita consultar, agregar e incluso graficar los datos de registro).

respuesta original

Si tiene la base de datos en su lugar, yo recomendaría usar esto para registros de auditoría en lugar del sistema de archivos.

Justificación:

• mecanografiada y clasificación normalizada de los datos (severity, action type, user, date ...)
• es más fácil encontrar los datos de auditoría (select ... from Audits where ...) vs Grep
• es más fácil de limpiar (por ejemplo,Delete from Audits where = Date ...)
• es más fácil de realizar copias de seguridad

La decisión de usar db existente o uno nuevo depende - si tiene varias aplicaciones (con sus propias bases de datos) y desea iniciar sesión/auditoría de todas las acciones en todas las aplicaciones centralmente, entonces un db centralizado podría tener sentido.

Como dices que quieres auditar la actividad del usuario, puede tener sentido auditar en la misma base de datos que la tabla/definición de tus usuarios (si corresponde).

Answer 2

Cualquiera de los dos funciona. Depende de tu preferencia.

Tenemos una base de datos central donde TODAS nuestras aplicaciones registran sus mensajes de error. Cada aplicación que escribimos está configurada en una tabla con una ID única, y la tabla de registro de errores contiene una referencia de clave externa a la AppId.

Esto ha sido una GRAN ventaja para nosotros al darnos un lugar para monitorear los errores. Lo habíamos hecho como un sistema de archivos o enviando correos electrónicos a una bandeja de entrada monitoreada en el pasado, pero pudimos crear una aplicación web bastante agradable para interactuar con los registros de errores. Tenemos diferentes niveles de error, y tenemos un "reconocido" campo de indicador, por lo que tenemos una página donde podemos ver los eventos no reconocidos por la gravedad, etc.,

Answer 3

Estoy de acuerdo con lo anterior con la excepción, tal vez obvia, de las fallas en la base de datos de registro que harían problemático el registro en la base de datos. Esto me ha surgido en el pasado ya que estaba lidiando con failovers de red poco frecuentes pero regulares.

Answer 4

¿Deberíamos registrar esto para decir un archivo txt usando FileSystemObject o registrarlo en una base de datos MSSQL?

Otra idea es escribir el archivo de registro en XML y luego consultarlo usando XPath. Me gusta pensar que esto es lo mejor de ambos mundos.

Answer 5

Mirando las respuestas, creo que la respuesta puede ser ambas.

Si es probable que se produzca un error de usuario durante el uso previsto (por ejemplo, el usuario ingresa un correo electrónico no válido, etc.), debe ir a una base de datos para aprovechar las consultas fáciles.

Si se trata de un error de código que no debería suceder (no se puede obtener el nombre de usuario de un usuario conectado), eso debe reservarse para un archivo txt.

Esto también divide los errores entre no crítico y crítico. ¡Ojalá la lista de errores críticos se quede pequeña!

Estoy creando un prototipo rápido de un nuevo proyecto en este momento, así que me quedaré con el txt por ahora.

En otra nota, el correo electrónico es ideal para esto. Posiblemente podría enviarlos por correo electrónico a una cuenta de "error" y no almacenarlos localmente. Sin embargo, esto comparte el riesgo de la base de datos de malas conexiones.