Tablas de historial de pros, contras y trampas - uso de desencadenadores, procedimiento almacenado o a nivel de aplicación [cerrado]

Question

Actualmente estoy jugando con la idea de contar la historia de tablas para algunos de mis tablas en mi base de datos.Básicamente tengo la tabla principal y una copia de la tabla con una fecha de modificación y una columna acción para almacenar lo que la acción se realiza por ejemplo Update,Delete e Insert.

Hasta ahora no puedo pensar en tres lugares diferentes que usted puede hacer la historia de la mesa de trabajo.

• Los desencadenadores de la tabla principal de update, insert y delete.(Base de datos)
• Los procedimientos almacenados.(Base de datos)
• Capa de aplicación.(Aplicación)

Mi pregunta principal es, ¿cuáles son los pros, los contras y trampas de realizar el trabajo en cada una de estas capas.

Una de las ventajas que puedo pensar por el uso de los factores desencadenantes es que la integridad se mantiene siempre no importa qué programa es implmentated en la parte superior de la base de datos.

Answer 1

Me ponerlo de esta manera:

• procedimientos almacenados: que están anuladas si modifica la tabla directamente. Seguridad en la base de datos puede controlar este
• aplicación: mismo trato. También si usted tiene múltiples aplicaciones, posiblemente en diferentes idiomas, tiene que ser implementado en cada pila, que es algo redundante; y
• disparadores: transparente para la aplicación y capturará todos los cambios. Este es mi método preferido.

Answer 2

Los desencadenantes son la forma más rápida y más fácil de conseguir la historia sencilla. La siguiente información se supone un ejemplo más complejo, donde la historia de procesamiento puede incluir algunas reglas de negocio y puede requerir la información de registro que no se encuentra en la tabla siendo rastreado.

Para los que piensan que los desencadenantes son más seguros que los procedimientos almacenados, ya que no pueden ser anuladas les recuerdo que están haciendo el siguiente supuesto:

!

) Permisos de que existan usuarios de parada de la ejecución de DISABLE TRIGGER [pero entonces también podrían existir permisos para limitar todos los accesos a la base de datos a excepción de EXECUTE en sprocs que es un patrón común para las aplicaciones empresariales] - por lo tanto, hay que suponer permisos correctos y por lo tanto, sprocs iguales disparadores en términos de seguridad y capacidad de ser anulada

!) En función de la base de datos puede ser posible para ejecutar sentencias de actualización que no se activan los factores desencadenantes. Podría aprovechar el conocimiento de la profundidad de ejecución del trigger anidada para eludir un disparador. La única solución segura incluye la seguridad en la base de datos y limitar el acceso a los datos utilizando mecanismos sólo aprobados -. Sean estos disparadores, procedimientos almacenados o capas de acceso de datos

Creo que las opciones son claras aquí. Si los datos se accede por múltiples aplicaciones a continuación, que desea controlar la historia de la capa común más bajo y esto va a significar la base de datos.

Siguiendo la lógica anterior, la elección de los factores desencadenantes o procedimientos almacenados de nuevo depende de si el procedimiento almacenado es la capa común más bajo. Usted debe preferir el sproc sobre el gatillo como se puede controlar el rendimiento, y los efectos secundarios mejor y el código es más fácil de mantener.

Los desencadenantes son aceptables, pero trate de asegurarse de que no se aumenta cerraduras mediante la lectura de los datos fuera de las tablas de actualización. Límite dispara a inserta en las tablas de registro, de registro sólo lo que necesita.

Si la aplicación utiliza una capa de acceso lógico común y es poco probable que esto cambiaría con el tiempo yo preferiría para implementar la lógica aquí. Utilice una cadena de patrón de Responsabilidad y una arquitectura plug-in, conducir esto desde la inyección de dependencias para permitir todo tipo de procesamiento en el que el módulo de la historia, incluyendo la tala completamente diferentes tipos de tecnología, diferentes bases de datos, un servicio de la historia o cualquier otra cosa que usted podría imaginar.

Answer 3

Han estado utilizando el gatillo enfoque basado durante años y que definitivamente ha funcionado bien para nosotros, pero entonces usted tiene los siguientes puntos a reflexionar sobre:

1. Los desencadenadores de un uso excesivo (es decir, un multi-tenant SaaS basada en la aplicación) puede ser extremadamente caro

2. En algunos escenarios, algunos campos pueden obtener redundante.Los desencadenantes son buenas sólo cuando son muy claras en los campos a ser registrados;aunque el uso de una aplicación que podría tener un interceptor de la capa que podría ayudarle a iniciar determinados campos basados en la "configuración";aunque con su propia parte de los gastos generales

3. Sin una adecuada base de datos de control, una persona puede desactivar fácilmente los factores desencadenantes, modificar los datos y permitir a los factores desencadenantes;todos sin levantar las alarmas

4. En el caso de las aplicaciones web, donde se establecen las conexiones de una piscina, de seguimiento de los usuarios reales que hizo los cambios puede ser tedioso.Una posible solución sería tener el "EditedBy" campo en cada tabla de transacciones.

Answer 4

una tardía pero añade par de opciones que se pueden considerar.

captura de datos modificados: Esta característica está disponible en SQL Server 2008 R2 + pero sólo en Enterprise edition. Que le permite seleccionar tablas que desea rastrear y SQL Server va a hacer el trabajo para usted. Funciona mediante la lectura de registro de transacciones y llenar tablas con datos de historia.

Lectura de registro de transacciones: Si la base de datos está en modo de recuperación completa después del registro de transacciones se puede leer y detalles sobre las transacciones casi se puede encontrar.

Lo malo es que esto no es apoyado por defecto. Las opciones son para leer registro de transacciones utilizando funciones no documentadas como herramientas fn_dblog o de terceros, como ApexSQL Log .

los factores causales: funciona muy bien para la pequeña cantidad de mesas donde no hay demasiados factores desencadenantes que administrar. Si usted tiene una gran cantidad de tablas que desee auditar, entonces debería considerar alguna herramienta de terceros para esto.

Todos estos trabajos a nivel de base de datos y son completamente transparentes para la aplicación.

Answer 5

Los desencadenantes son la única manera confiable para capturar los cambios. Si lo haces en procedimientos almacenados o la aplicación, siempre se puede entrar y SQL distancia un cambio que no tiene un registro de (inadvertidamente). Por supuesto, alguien que no quiere que deje un registro puede desactivar los factores desencadenantes. Pero prefiere forzar a alguien para deshabilitar el registro que esperan que recuerdan a incluirlo.

Answer 6

Por lo general, si se elige la capa de aplicación, puede diseñar su código de aplicación para hacer el registro en un solo punto, que se encargará de todo consistentemente su tabla histórica. diferente desencadenantes son un enfoque más complicado de mantener, ya que son (dependiendo de la tecnología db) replicado para cada mesa: en el caso de cientos de mesas de la cantidad de código para el gatillo coud ser un problema.

Si usted tiene una organización de apoyo que mantendrá el código que está escribiendo ahora, y no se sabe quién va a mantener su código (típico para las grandes industrias) no se puede asumir que es el nivel de habilidad de la persona que va a hacer fijar en su aplicación, en ese caso es mejor en mi opinión, para hacer la tabla histórica principio de funcionamiento lo más simple posible, y la capa de aplicación es probablemente el mejor lugar para este propósito.