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

no puedo iniciar servicio sql server 2014

Question

Todavía estamos usando el clásico ASP 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

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 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 campo de bandera "reconocida", por lo que tenemos una página donde podemos ver los eventos no reconocidos por gravedad, etc.

Answer 2

Estoy de acuerdo con lo anterior con la excepción, tal vez obvia, de registrar las fallas de la base de datos 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 3

¿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 4

Al mirar las respuestas, creo que la respuesta puede ser ambas.

Si es probable que se produzca un error del usuario durante el uso previsto (p. Ej., El usuario ingresa un correo electrónico no válido, etc.), debe ingresar 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 texto por ahora.

En otra nota, el correo electrónico es excelente 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.

Answer 5

Editar

En retrospectiva, una mejor respuesta es iniciar sesión en el sistema de archivos BOTH (primero, inmediatamente) y luego en una base de datos centralizada (incluso si se retrasa).

El razonamiento detrás de escribir al 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 pérdida 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 empresarial como Splunk pueden configurarse para raspar los archivos de registro del servidor local (por ejemplo, escritos por log4net , el Logging Application Block log4net , etc.) y luego centralizarlos en una base de datos con capacidad de búsqueda, donde los datos registrados pueden extraerse. graficado, mostrado en los paneles, 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 remoto de la base de datos funcionan, el 99% de casos de uso para tratar de encontrar algo en un registro el archivo 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, recomendaría usar esto para los registros de auditoría en lugar del sistema de archivos.

Razón fundamental:

• tipificación y clasificación normalizada de datos ( severity, action type, user, date ... )
• es más fácil encontrar datos de auditoría ( select ... from Audits where ... ) versus Grep
• es más fácil de limpiar (por ejemplo, Delete from Audits where = Date ... )
• es más fácil hacer una copia de seguridad

La decisión de usar una base de datos existente o nueva depende - si tiene múltiples aplicaciones (con sus propias bases de datos) y desea registrar / auditar todas las acciones en todas las aplicaciones centralmente, entonces una base de datos centralizada podría tener sentido.

Como dice que desea auditar la actividad del usuario, podría tener sentido auditar en la misma base de datos que la tabla / definición de los usuarios (si corresponde).