Cascade on ¿Eliminar o usar Triggers?

Question

Estoy pasando por un proyecto que he asumido, y en el lado de la base de datos me he dado cuenta de que los programadores anteriores han escrito una serie de factores desencadenantes para eliminar registros secundarios. El caso es que estos registros ya tienen una relación de clave externa con el registro principal que estoy eliminando. Los desencadenadores de eliminación no son más que simples declaraciones de eliminación para los registros secundarios.

¿Existe un beneficio para escribir un disparador para borrar registros secundarios, o puedo cambiarlo a caer en cascada sobre el borrado y estar bien?

Estoy usando MSSQL 2008.

Answer 1

CASCADE DELETE en MSSQL Server solo puede conectarse en cascada a una sola tabla. Si tiene dos tablas con relaciones de clave externa con una tabla de dimensiones, solo puede eliminar en cascada a una de ellas. (Esto es para evitar eliminaciones en cascada a través de múltiples caminos y creando conflictos, tanto como C++ permite la herencia múltiple, pero C# sólo permite la herencia simple)

Cuando este es el caso, se ven obligados a utilizar disparadores o específicamente manejar el caso en su código.

Por esta razón, he visto a muchas personas optar por el uso de factores desencadenantes en todos los casos. Incluso cuando solo hay una mesa extranjera. Esto garantiza la coherencia y, por lo tanto, las personas saben qué buscar cuando mantienen la base de datos.

Si se pudiera conectar en cascada una eliminación de más de una tabla, diría que sería la opción más preferible. Esta limitación, sin embargo, enturbia las aguas y actualmente estoy más a favor de que los desencadenantes posean todos esos comportamientos. La sobrecarga en el uso de desencadenantes para eliminaciones y actualizaciones en cascada es solo menor en términos de codificación, pero permite prácticas estándar que son verdaderamente genéricas.

EDIT:

Es posible que desee mover la 'respuesta aceptada' a otra persona, he trabajado que estaba equivocado Abot lo anterior.

Puede tener varias tablas de hechos SOBRE han DELETE CASCADE clave Exteriores Contraints a una tabla de dimensiones signle.

lo que no puede hacer es tener una tabla de hechos se tienen ON DELETE CASCADE Exteriores principales limitaciones para múltiples tablas de medidas.

Entonces, por ejemplo ...
- Tabla de dimensiones [persona] (identificaciones INT,)
- Tabla de dimensiones [ex] (id INT IDENTIDAD,)
- Cara de la tabla [Exam_Score] (person_id INT, exam_id INT, partitura INT)

Si se eliminan la Persona o el Examen, querrá que también se eliminen los registros Exam_Score asociados.

Esto no es posible utilizando ON DELETE CASCADE en el servidor MS SQL, por lo tanto, la necesidad de desencadenantes.

(disculpas a Mehrdad que intentó explicar esto a mí, pero me he perdido por completo su punto.)

Answer 2

Manténgase alejado de desencadenantes innecesarios.

Ir con ON DELETE CASCADE si eso es todo lo que necesita hacer.

Answer 3

Usaría cascada en la eliminación, pero eso es solo si definitivamente desea eliminar el elemento secundario si se elimina el documento principal.

Si tiene alguna lógica condicional (solo elimino el elemento secundario si se eliminó un domingo), a continuación, use un desencadenador.

me acaba de cambiar a cascade on delete, en un sistema de desarrollo, a continuación, ejecutar mis pruebas de unidad y asegurarse de que nada se rompe.

Answer 4

casi estoy de acuerdo con Dems aquí excepto yo uso ON DELETE CASCADE (y ON UPDATE CASCADE para esa materia) acciones referenciales siempre que sea posible y sólo recurrir al uso de disparadores cuando sea necesario. También consideraría revocar los permisos de las tablas y forzar el uso de procesos almacenados 'auxiliares' para las eliminaciones y actualizaciones.

Llámame un optimista, pero creo que a) mi código sobrevivirá a una futura versión de MS SQL Server yb) el equipo de SQL Server un día pronto reparará la limitación de 'una ruta en cascada', en en qué punto reemplazaré los desencadenantes con acciones referenciales en cascada :)