Consideraciones de rendimiento para disparadores vs restricciones

Question

Estoy tratando de averiguar si debo usar lógica empresarial crítica en un desencadenante o restricción dentro de mi base de datos.
Hasta ahora he agregado lógica en los disparadores, ya que me da el control sobre lo que sucede a continuación y significa que puedo proporcionar mensajes de usuario personalizados en lugar de un error que probablemente confundirá a los usuarios.

¿Hay alguna ganancia de rendimiento notable al usar restricciones sobre los disparadores y cuáles son las mejores prácticas para determinar cuál usar?

Answer 1

¡Restricciones sin duda!

• Con restricciones, usted especifica principios relacionales, es decir, hechos sobre sus datos. Nunca necesitará cambiar sus restricciones, a menos que algunos hechos cambien (es decir, nuevos requisitos).

• Con los desencadenantes, usted especifica cómo manejar los datos (en insertos, actualizaciones, etc.). Este es un " no relacional " forma de hacer las cosas.

Para explicarme mejor con una analogía: la forma correcta de escribir una consulta SQL es especificar "lo que quieres". en lugar de " cómo obtenerlo " - deje que el RDBMS descubra la mejor manera de hacerlo por usted. Lo mismo se aplica aquí: si usa disparadores, debe tener en cuenta varias cosas como el orden de ejecución, la conexión en cascada, etc. Deje que SQL lo haga por usted con restricciones si es posible.

Eso no quiere decir que los desencadenantes no tengan usos. Lo hacen: a veces no puede usar una restricción para especificar algún hecho sobre sus datos. Sin embargo, es extremadamente raro. Si le sucede mucho , entonces probablemente haya algún problema con el esquema.

Answer 2

Mejores prácticas : si puede hacerlo con una restricción, use una restricción.

Los activadores no son tan malos como desacreditan (si se usan correctamente), aunque siempre usaría una restricción siempre que sea posible. En un RDMS moderno, la sobrecarga de rendimiento de los activadores es comparable a las restricciones (por supuesto, eso no significa que alguien no pueda colocar un código horrible en un activador).

Ocasionalmente, es necesario usar un desencadenador para imponer una restricción 'compleja', como la situación de querer imponer que uno y solo uno de los dos campos de clave externa de una tabla están rellenos (he visto esta situación en algunos dominios modelos).

El debate sobre si la lógica de negocios debería residir en la aplicación en lugar de la base de datos, depende en cierta medida del entorno; Si tiene muchas aplicaciones que acceden a la base de datos, tanto las restricciones como los desencadenantes pueden servir como protección final para que los datos sean correctos.

Answer 3

Los desencadenantes pueden convertirse en un problema de rendimiento. Casi al mismo tiempo que sucede, también se han convertido en una pesadilla de mantenimiento. No puede darse cuenta de lo que está sucediendo y (¡bonificación!) La aplicación se comporta de forma errática con " espuria " problemas de datos [En realidad, son problemas de activación.]

Ningún usuario final toca SQL directamente. Usan programas de aplicación. Los programas de aplicación contienen lógica empresarial de una manera mucho más inteligente y fácil de mantener que los desencadenantes. Ponga la lógica de la aplicación en los programas de aplicación. Poner datos en la base de datos.

A menos que usted y sus " usuarios " no comparta un lenguaje común, puede explicarles las infracciones de restricción. La alternativa, no explicar, convierte una base de datos simple en un problema porque combina los datos y el código de la aplicación en un atolladero imposible de mantener.

" ¿Cómo obtengo la seguridad absoluta de que todos están usando el modelo de datos correctamente? "

Dos (y media) técnicas.

1. Asegúrese de que el modelo es correcto : coincide con el dominio del problema del mundo real. Sin trucos ni soluciones o accesos directos que solo se pueden resolver a través de explicaciones complejas, procedimientos almacenados y desencadenantes.

2. Ayuda a definir la capa de modelo de negocio de las aplicaciones. La capa de código de aplicación que todos comparten y reutilizan.

   a. Además, asegúrese de que la capa del modelo satisfaga las necesidades de las personas. Si la capa modelo tiene los métodos y las colecciones correctas, hay menos incentivos para omitirla para obtener acceso directo a los datos subyacentes. En general, si el modelo es correcto, esto no es una preocupación profunda.

Los disparadores son un choque de trenes que espera suceder. Las restricciones no lo son.

Answer 4

Además de las otras razones para usar restricciones, el optimizador de Oracle puede usar restricciones para su ventaja.

Por ejemplo, si tiene una restricción que dice (Amount > = 0) y luego consulta con WHERE (Amount = -5) Oracle sabe de inmediato que hay no hay filas coincidentes.

Answer 5

Las restricciones y los desencadenantes son para 2 cosas diferentes. Las restricciones se utilizan para restringir el dominio (entradas válidas) de sus datos. Por ejemplo, un SSN se almacenaría como char (9), pero con una restricción de [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [ 0-9] [0-9] [0-9] (todo numérico).

Los disparadores

son una forma de imponer la lógica empresarial en su base de datos. Tomando el SSN nuevamente, tal vez sea necesario mantener un seguimiento de auditoría cada vez que se cambia un SSN, eso se haría con un disparador,

En general, los problemas de integridad de datos en un RDBMS moderno pueden manejarse con alguna variación de una restricción. Sin embargo, a veces se encontrará en una situación en la que la normalización inadecuada (o los requisitos modificados, lo que resulta en una normalización ahora incorrecta) evita una restricción. En ese caso, un desencadenante puede ser capaz de imponer su restricción, pero es opaco al RDBMS, lo que significa que no se puede usar para la optimización. También está "oculto" Lógica, y puede ser un problema de mantenimiento. Decidir si refactorizar el esquema o usar un disparador es una decisión decisiva en ese momento.

Answer 6

En general, preferiría las restricciones y mi código detectaría los errores del servidor SQL y presentaría algo más amigable para el usuario.

Answer 7

@onedaywhen

Puede tener una consulta como una restricción en SQL Server, solo tiene que ser capaz de encajar en una función escalar: http://www.eggheadcafe.com/software/aspnet/30056435/check-contraints-and-tsql.aspx

Answer 8

@Mark Brackett: " Las restricciones se usan para restringir el dominio ... Los disparadores son una forma de imponer la lógica de negocios " ;: No es tan simple en SQL Server porque la funcionalidad de sus restricciones es limitada, por ejemplo. aún no está lleno SQL-92. Tome el ejemplo clásico de una 'clave primaria' secuenciada en una tabla de base de datos temporal: idealmente usaría una restricción CHECK con una subconsulta para evitar la superposición de los períodos para la misma entidad, pero SQL Server no puede hacer eso, así que tengo que usar una desencadenar. También falta de SQL Server la capacidad de SQL-92 para diferir la comprobación de restricciones, pero en su lugar se verifican (en efecto) después de cada declaración SQL, por lo que, de nuevo, puede ser necesario un desencadenante para solucionar las limitaciones de SQL Server.

Answer 9

Si es posible usar restricciones. Tienden a ser un poco más rápidos. Los desencadenadores deben usarse para una lógica compleja que una restricción no puede manejar. La escritura de disparadores también es complicada y si encuentra que debe escribir un disparador, asegúrese de usar declaraciones basadas en conjuntos porque los tigres operan contra todo el inserto, actualización o eliminación (Sí, habrá ocasiones en que más de un registro se vea afectado, planifique en eso!), no solo un registro a la vez. No utilice un cursor en un disparador si se puede evitar.

En cuanto a si colocar la lógica en la aplicación en lugar de un desencadenante o restricción. ¡¡¡NO HAGAS ESO!!! Sí, las aplicaciones deben tener verificaciones antes de enviar los datos, pero la integridad de los datos y la lógica de negocios deben estar en el nivel de la base de datos o sus datos se desordenarán cuando se enganchen varias aplicaciones, cuando se realicen inserciones globales fuera de la aplicación, etc. Datos la integridad es clave para las bases de datos y debe aplicarse en el nivel de la base de datos.

Answer 10

@Meff: hay problemas potenciales con el enfoque de usar una función porque, simplemente, las restricciones CHECK de SQL Server fueron diseñadas con una sola fila como la unidad de trabajo y tienen fallas cuando se trabaja en un conjunto de resultados. Para obtener más detalles sobre esto, consulte: [ http://blogs.conchango.com/davidportas/archive/2007/02/19/Trouble-with-CHECK-Constraints.aspx] [1] .

[1]: Blog de David Portas: Problema con las restricciones de VERIFICACIÓN.

Answer 11

Igual que Skliwz. Solo para hacerle saber que un uso canónico del disparador es la tabla de auditoría. Si muchos procedimientos actualizan / insertan / eliminan una tabla que desea auditar (quién modificó qué y cuándo), el desencadenante es la forma más sencilla de hacerlo. una forma es simplemente agregar un indicador en su tabla (activo / inactivo con alguna restricción de unicidad) e insertar algo en la tabla de auditoría.

Otra forma si desea que la tabla no contenga los datos históricos es copiar la fila anterior en su tabla de auditoría ...

Muchas personas tienen muchas formas de hacerlo. Pero una cosa es segura, tendrá que realizar una inserción para cada actualización / inserción / eliminación en esta tabla

Para evitar escribir el inserto en docenas de lugares diferentes, aquí puede usar un disparador.

Answer 12

Estoy de acuerdo con todos aquí acerca de las restricciones. Úsalos tanto como sea posible.

Existe una tendencia a sobreutilizar los desencadenantes, especialmente con los nuevos desarrolladores. He visto situaciones en las que un disparador dispara otro disparador que dispara otro disparador que repite el primer disparador, creando un disparador en cascada que vincula su servidor. Este no es un usuario óptimo de activadores; o)

Dicho esto, los desencadenantes tienen su lugar y deben usarse cuando sea apropiado. Son especialmente buenos para rastrear cambios en los datos (como mencionó Mark Brackett). Debe responder la pregunta "¿Dónde tiene más sentido poner mi lógica de negocios"? La mayoría de las veces creo que pertenece al código, pero tienes que mantener la mente abierta.