Desencadenadores de base de datos

Question

En el pasado, nunca he sido un fan de utilizar desencadenadores en tablas de base de datos.A mí siempre representado "magia" que iba a suceder en la base de datos secundarios, lejos muy lejos de el control de mi código de la aplicación.Yo también quería limitar la cantidad de trabajo que el DB tenía que hacer, como es generalmente un recurso compartido y yo siempre supuse que podrían llegar a ser muy caro en alto en situaciones de carga.

Dicho esto, he encontrado un par de casos en donde se desencadena tener un sentido para su uso (al menos en mi opinión le dan sentido).Aunque recientemente, me encontré en una situación en la que yo a veces puede ser que necesite para "eludir" el gatillo.Me sentí muy culpable por tener que buscar maneras de hacer esto, y creo que un mejor diseño de base de datos para aliviar la necesidad de que este pasando por alto.Por desgracia, este DB es utilizado por múltiples aplicaciones, algunas de las cuales son mantenidas por un no coopera equipo de desarrollo que iba a gritar acerca de los cambios de esquema, así que me quedé atascado.

¿Cuál es el general consesus que hay sobre los desencadenantes?Amor em?Odio em?Creo que ellos sirven a un propósito en algunos de los escenarios?Creo que tienen una necesidad de omitir un desencadenador significa que no estamos haciendo mal"?

Answer 1

Los desencadenantes son generalmente utilizados incorrectamente, introducir errores y por lo tanto debe ser evitado.Nunca se diseño un disparador para hacer la integridad de la comprobación de restricciones que atraviesa las filas de una tabla (e.g "el salario promedio por departamento no puede exceder X).

Tom Kyte, VICEPRESIDENTE de Oracle ha indicado que prefiere eliminar los desencadenantes como una característica de Oracle base de datos debido a sus frecuentes papel en los bichos.Él sabe que es sólo un sueño, y los disparadores están aquí para quedarse, pero si podía iba a eliminar los desencadenantes de Oracle, él (junto con el CUANDO OTROS cláusula autónoma y de las transacciones).

Puede desencadenantes ser utilizados correctamente?Absolutamente.

El problema es que no se utilizan correctamente en la muchos de los casos que yo estaría dispuesto a dar cualquier beneficio percibido sólo para obtener deshacerse de los abusos (y errores) causados por ellos.- Tom Kyte

Answer 2

Pensar en un base de datos como un gran objeto - después de cada llamada a la misma, debe estar en un estado coherente lógicamente.

Las bases de datos se exponen a través de tablas, y mantener tablas y filas consistente se puede hacer con los desencadenadores.Otra manera de mantener la uniformidad es la de no permitir el acceso directo a las tablas, y sólo permitiendo que a través de procedimientos almacenados y vistas.

La desventaja de los factores desencadenantes es que cualquier acción puede invocar ellos;esta es también una fuerza que nadie lo va a arruinar la integridad del sistema a través de la incompetencia.

Como contrapunto, permitiendo el acceso a una base de datos sólo a través de procedimientos almacenados y vistas todavía permite el acceso de puerta trasera de permisos.Los usuarios con permisos suficientes son de confianza no para romper la integridad de base de datos, todos los demás el uso de procedimientos almacenados.

En cuanto a la reducción de la cantidad de trabajo:las bases de datos son increíblemente eficiente cuando no tienen que lidiar con el mundo exterior;sería realmente sorprendido de lo mucho incluso el proceso de conmutación se daña el rendimiento.Esa es otra ventaja de los procedimientos almacenados:en lugar de una docena de llamadas a la base de datos (y todos los viajes de ida y vuelta), hay uno.

Agrupar las cosas en un solo procedimiento almacenado está bien, pero ¿qué pasa cuando algo sale mal?Digamos que tienes 5 pasos y el primer paso falla, ¿qué sucede con los otros pasos?Usted necesita para añadir un montón de lógica en el que hay que atender esa situación.Una vez que usted comienza a hacer que usted pierda los beneficios del procedimiento almacenado en ese escenario.

La lógica de negocio tiene que ir a algún lugar, y hay un montón de implícita de las reglas de dominios incorporado en el diseño de una base de datos, relaciones, restricciones, etcétera, son un intento de codificar las reglas de negocio diciendo, por ejemplo, un usuario sólo puede tener una contraseña.Dado que has empezado a empujones de reglas de negocio en la base de datos del servidor por tener estas relaciones, y así sucesivamente, ¿dónde trazar la línea?Cuando se hace la base de datos de ceder la responsabilidad de la integridad de los datos, y empezar a confiar en las aplicaciones de llamadas y base de datos de los usuarios para obtener el derecho?Los procedimientos almacenados con estas reglas incrustados en ellos puede insertar una gran cantidad de poder político en manos de los Administradores de bases de datos.Se trata de cuántos niveles se va a existir en su arquitectura n-tier;si hay una presentación, negocio y capa de datos, donde se hace la separación entre el negocio y los datos de la mentira?¿Qué valor añadido tiene la capa de negocio agregar?Se ejecuta la capa de negocio en el servidor de base de datos como procedimientos almacenados?

Sí, creo que tener para evitar un desencadenador significa que no estamos haciendo mal";en este caso, un gatillo no es para usted.

Answer 3

Yo trabajo con web y de aplicaciones winforms en c# y me ODIO se activa con una pasión.Nunca me he encontrado con una situación en la que yo podría justificar el uso de un disparo en movimiento esa lógica en la capa de negocio de la aplicación y replicar el gatillo de la lógica.

Yo no hago ningún DTS tipo de trabajo ni nada de eso, así que no podrían ser algunos de los casos de uso para el uso de gatillo, pero si a nadie de mi equipo, dice que puede ser que desee para el uso de un disparador que mejor se han preparado sus argumentos bien porque me niego a permitir que desencadena ser agregadas a la base de datos en el que estoy trabajando.

Algunas razones por las que no me gusta de las causas:

• Se mueven lógica en la base de datos.Una vez que empiezas a hacer eso, usted está pidiendo un mundo de dolor porque usted pierde su depuración, su tiempo de compilación seguridad, el flujo de la lógica.Es todo cuesta abajo.
• La lógica de implementar no es fácilmente visible para todos.
• No todos los motores de base de datos de soporte de desencadenadores para su solución crea en las dependencias de los motores de base de datos

Estoy seguro de que podría pensar de más razones, en la parte superior de mi cabeza, pero esas son suficientes para mí, no para uso de desencadenadores.

Answer 4

"Nunca se diseño un disparador para hacer la integridad de la comprobación de restricciones que atraviesa las filas de una tabla" - yo no puedo estar de acuerdo.La pregunta es tagged 'SQL Server' y las restricciones CHECK' cláusulas en SQL Server no puede contener una subconsulta;peor aún, la aplicación parece tener un 'codificado' suposición de que un CHEQUE implica únicamente una sola fila para el uso de una función no es confiable.Así que si necesito una restricción que hace legítima la participación de más de una fila, y un buen ejemplo es la secuencia de clave principal en un clásico 'de tiempo válido' temporal mesa donde yo necesidad de evitar la superposición de los periodos para la misma entidad -- ¿cómo puedo hacer eso sin un trigger?Recuerda que esto es una clave principal, algo para asegurarme de tener la integridad de los datos, por lo que su aplicación en otro lugar que el DBMS es fuera de la cuestión.Hasta que las restricciones CHECK obtener subconsultas, no veo una alternativa al uso de disparadores para ciertos tipos de restricciones de integridad.

Answer 5

Los desencadenantes pueden ser muy útiles.Ellos también pueden ser muy peligrosas.Creo que están bien para la limpieza de la casa tareas como rellenar los datos de auditoría (creado por, fecha de modificación, etc) y en algunas bases de datos pueden ser utilizados para la integridad referencial.

Pero yo no soy un gran fan de poner un montón de lógica de negocios en ellos.Esto puede hacer que el apoyo problemático porque:

• es una capa adicional de código para la investigación
• a veces, como el OP aprendido, cuando se necesita hacer una revisión de datos el gatillo podría estar haciendo cosas con la suposición de que el cambio de los datos es siempre a través de una aplicación de la directiva y no de un desarrollador o administrador de la fijación de un problema, o incluso desde una aplicación diferente

Como para tener que evitar un disparador para hacer algo, eso podría significar que usted está haciendo algo mal, o podría significar que el gatillo está haciendo algo mal.

La regla general me gusta usar con los factores desencadenantes es mantenerlos ligero, rápido, simple, y como no invasivos como sea posible.

Answer 6

Me encuentro a mí mismo evitando los desencadenantes cuando se hace de forma masiva datos de las importaciones.Creo que es justificado en tales circunstancias.

Si usted termina evitando los factores desencadenantes muy a menudo, sin embargo, es probable que necesite para echar otro vistazo a lo que los puso allí en el primer lugar.

En general, yo iba a votar por "los cuales sirven a un propósito en algunos de los escenarios".Siempre estoy nervioso acerca de las implicaciones de la ejecución.

Answer 7

Yo no soy un fan, personalmente.Voy a utilizar, pero sólo cuando descubro un cuello de botella en el código que puede ser desactivada por el movimiento de las acciones en un desencadenador.En general, prefiero la sencillez y una manera de mantener las cosas simples es mantener la lógica en un lugar de la aplicación.También he trabajado en puestos de trabajo donde el acceso es muy compartimentado.En esos ambientes, la más código debo empacar en desencadena la más de la gente que tengo a participar para que incluso los más simples correcciones.

Answer 8

La primera vez que utiliza desencadena un par de semanas atrás.Hemos cambiado a lo largo de una producción de servidor de SQL 2000 a SQL 2005 y se encontró que los conductores se comportan de manera diferente con NText campos (almacenamiento de un documento XML de gran tamaño), disminuyendo el último byte.He utilizado un disparo como un arreglo temporal para añadir un extra de maniquí byte (un espacio) para el final de los datos, la solución de nuestro problema hasta que una solución adecuada podría ser desplegado.

Aparte de este especial, temporal caso, me gustaría decir que me gustaría evitar, ya que esconden lo que está pasando, y la función que proporcione debe ser manejado explícitamente por el programador más que como algunos de los secretos de la magia.

Answer 9

Honestamente, el único momento en que el uso de activadores para simular un índice único que se le permite tener NULA de que no cuente para la singularidad.

Answer 10

En cuanto a la reducción de la cantidad de trabajo:las bases de datos son increíblemente eficiente cuando no tienen que lidiar con el mundo exterior;sería realmente sorprendido de lo mucho incluso el proceso de conmutación se daña el rendimiento.Esa es otra ventaja de los procedimientos almacenados:en lugar de una docena de llamadas a la base de datos (y todos los viajes de ida y vuelta), hay uno.

esto es un poco off topic, pero también debe ser consciente de que sólo estás buscando en este de un potencial positivo.

Agrupar las cosas en un solo procedimiento almacenado está bien, pero ¿qué pasa cuando algo sale mal?Digamos que tienes 5 pasos y el primer paso falla, ¿qué sucede con los otros pasos?Usted necesita para añadir un montón de lógica en el que hay que atender esa situación.Una vez que usted comienza a hacer que usted pierda los beneficios del procedimiento almacenado en ese escenario.

Answer 11

Total de la fan,

pero tenemos que usarlo con moderación cuando,

• Necesidad de mantener la coherencia (especialmente cuando las tablas de dimensiones se utilizan en un almacén y tenemos que relacionar los datos en la tabla de hechos con su justa dimensión .En algún momento, el adecuado fila en la tabla de dimensión puede ser muy costoso para calcular de manera que usted desea que la clave para ser escrito directamente a la tabla de hechos, una buena manera de mantener esa "relación" con el gatillo.

• Necesidad de cambios en el registro (en una tabla de auditoría, por ejemplo, es útil saber qué @@usuario que hizo el cambio y cuándo ocurrió)

Algunos RDBMS como sql server 2005 también proporcionar usted con los desencadenadores de CREAR/MODIFICAR/DROP (así que usted puede saber quién crea lo de la tabla, cuando, dejaba lo de la columna, cuando, etc..)

Honestamente, utilizando disparadores en los 3 escenarios, no veo por qué tendría usted alguna vez la necesidad de "deshabilitar" de ellos.

Answer 12

La regla general es:no uso de desencadenadores.Como se mencionó antes, se agrega una sobrecarga y complejidad que se puede evitar fácilmente mediante el movimiento de la lógica de la base de datos de la capa.

También, en MS SQL Server, los desencadenadores se activa una vez por cada comando sql, y no por fila.Por ejemplo, la siguiente instrucción sql que se ejecutará el disparador una sola vez.

UPDATE tblUsers
SET Age = 11
WHERE State = 'NY'

Muchas personas, incluyéndome a mí, estaban bajo la impresión de que los factores desencadenantes son despedidos en cada fila, pero este no es el caso.Si usted tiene una instrucción sql como la de arriba que puede cambiar los datos en más de una fila, es posible que desee incluir un cursor para actualizar todos los registros afectados por el gatillo.Usted puede ver cómo esto puede ser complicado muy rápidamente.