Dilema: Cascade delete or Join delete

Question

No es una pregunta específica, más bien una pregunta general.

Cuando tiene que realizar una eliminación en varias tablas en una relación 1: M, ¿es mejor hacer una restricción FK con una eliminación en cascada o unir las tablas en la instrucción delete?

Tenía un proyecto antiguo que tenía instrucciones de eliminación separadas para las tablas relacionadas, y algunas veces algunas de las declaraciones no se ejecutaban y la integridad de los datos se veía comprometida. Tuve que tomar una decisión entre los dos, así que pensé un poco cuál sería la mejor solución.

También hay una opción para realizar un procedimiento almacenado o una transacción.

Así que estoy buscando una opinión o consejo ...?

Answer 1

Si su base de datos tiene una RI adecuada definida para ella, entonces no debería haber ningún caso de integridad de datos comprometida. Todas las tablas relacionadas deben tener RI declarativa, lo que significa que no se puede eliminar un elemento primario mientras todavía tenga elementos secundarios.

Además, si tiene un código que solo está borrando algunas de las filas a veces, entonces esa es una codificación deficiente y pruebas deficientes. Este tipo de acciones debe ser una transacción única. Su sugerencia de utilizar un procedimiento almacenado es un gran enfoque para resolver ese problema y es bastante estándar.

Como ya se ha mencionado, los activadores en cascada tienen el peligro de eliminar filas que alguien no tenía la intención de eliminar. Tenga en cuenta que, en ocasiones, es posible que las personas accedan a sus datos desde algún lugar fuera de su aplicación, especialmente cuando solucionan problemas de datos. Cuando alguien accidentalmente intenta eliminar al padre incorrecto y obtiene un error de RI que es bueno. Cuando accidentalmente intentan eliminar al padre incorrecto, no solo elimina ese padre sino 20 niños en otras 5 tablas, eso es malo.

Además, las eliminaciones en cascada están muy ocultas. Si un desarrollador está codificando una eliminación para el padre, entonces debe saber que tiene que usar el procedimiento de eliminación de almacenamiento para cuidar a los niños.Es mucho más preferible que un desarrollador no codifique eso, obtenga un error y corrija su código (o se dé cuenta de que realmente no desea hacer todo eso) de lo que es tener un programador para lanzar una eliminación y tener nadie se da cuenta de que está matando a los niños hasta que el código se haya puesto en marcha.

IMO, prefiero que mis desarrolladores conozcan la aplicación en lugar de hacer que les resulte más fácil ignorarla.

Answer 2

Yo diría que es más seguro usar una eliminación en cascada. Si decide usar uniones, debe recordar usarlas cada vez que borre algo de la tabla padre; e incluso si tiene la disciplina suficiente para hacerlo, no puede estar seguro de sus compañeros de trabajo o las personas que admitirán su software en el futuro. Además, codificar tal conocimiento sobre las relaciones de tabla más de una vez viola el principio DRY.

Si utiliza una eliminación de cascada, nadie tiene que recordar nada, y las filas secundarias siempre se eliminarán según sea necesario.

Answer 3

La eliminación en cascada causa muchos problemas y, por lo tanto, es extremadamente peligroso. No recomendaría su uso. En primer lugar, supongamos que necesito eliminar el registro que tiene millones de registros secundarios. Puede bloquear la base de datos y dejarla inutilizable durante horas. Conozco muy pocos dbas que permitan que la eliminación en cascada se use en sus bases de datos.

A continuación, no ayuda con la integridad de los datos si ha definido los FK. Una eliminación con registros hijo todavía existente fallará, lo que es una buena cosa . Quiero que la eliminación del cliente falle si tiene pedidos existentes, por ejemplo. La eliminación en cascada utilizada de forma irreflexiva (como suele ocurrir en mi experiencia) puede hacer que se eliminen cosas que realmente no desea eliminar.

Answer 4

Utilice ambos!

Las eliminaciones manuales "unidas" suelen ser mejores para evitar interbloqueos y otros problemas de contención, ya que puede dividir las eliminaciones en unidades de trabajo más pequeñas. Si tiene una disputa, es definitivamente más fácil encontrar la causa del conflicto.

Según lo indicado "Delete Cascade" garantizará absolutamente la integridad referencial.

Por lo tanto, use ambos - haga eliminaciones explícitas de los "hijos" en sqls unidos para evitar interbloqueos y problemas de rendimiento. Pero deje "CASCADE DELETE" habilitado para atrapar todo lo que haya olvidado. Como no debe quedar ningún hijo cuando elimine al padre, esto no le costará nada, a menos que haya cometido un error con sus eliminaciones, en cuyo caso el costo vale la pena para mantener su integridad referencial.