Pregunta

El desarrollador principal en un proyecto en el que estoy involucrado en dice que es una mala práctica que depender de cascadas para borrar registros relacionados.

No veo cómo esto es malo, pero me gustaría saber su opinión sobre si / qué es.

¿Fue útil?

Solución

Voy a aclarar esto diciendo que rara vez eliminar filas periodo . En general, la mayoría de los datos que desea conservar. Sólo tiene que marcar como eliminado por lo que no se mostrará a los usuarios (es decir, que para ellos aparece como eliminado). Por supuesto que depende de los datos y para algunas cosas (por ejemplo cesta de la compra contenidos) en realidad borrando los registros cuando el usuario se vacía su cesta está muy bien.

Sólo puedo suponer que el problema aquí es que puede eliminar accidentalmente registros que en realidad no desea eliminar. La integridad referencial debe evitar esto, sin embargo. Así que no puedo ver realmente una razón en contra de este no sea el caso, por ser explícita.

Otros consejos

Yo diría que siga el principio de la menor sorpresa.

eliminaciones en cascada no deben causar la pérdida inesperada de datos. Si una eliminación requiere registros relacionados a ser borrados, y el usuario tiene que saber que esos registros se van a desaparecer, no se deben utilizar las eliminaciones en cascada a continuación. En su lugar, el usuario debe estar obligado a eliminar de manera explícita los registros relacionados, o se proporcionará una notificación.

Por otro lado, si la tabla se relaciona con otra tabla que es de naturaleza temporal, o que contiene registros que no serán necesarios cuando la entidad matriz se ha ido, a continuación, eliminaciones en cascada pueden estar bien.

Dicho esto, yo prefiero Estado mis intenciones explícitamente borrando los registros relacionados en el código, en lugar de depender de eliminaciones en cascada. De hecho, en realidad nunca he utilizado una eliminación en cascada eliminar implícitamente registros relacionados. También, utilizo eliminación suave mucho, tal como se describe por Cletus.

Nunca uso eliminaciones en cascada. ¿Por qué? Debido a que es muy fácil cometer un error. Mucho más seguro para requerir aplicaciones cliente a explícitamente eliminar (y cumplir con las condiciones para su eliminación, como eliminar FK refirió registros.)

De hecho, las deleciones en sí misma puede ser evitado mediante el marcado de registros como eliminado o se mueve en tablas de archivos / historia.

En el caso de marcar registros como eliminado, depende de la proporción relativa de marcado como datos eliminados, ya que SELECTs tendrán que filtrar en 'isDeleted = false' un índice sólo será utilizada si menos de 10% (aproximadamente, dependiendo de RDBMS) de los registros están marcados como eliminados.

¿Cuál de estos 2 escenarios prefiere:

1) Desarrollador viene a ti, dice "Hey, esto no va a funcionar borrar". Los dos mira en él y encontrar que fue accidentalmente tratando de eliminar todo el contenido de la tabla. Los dos tienen una risa, y volver a lo que estaba haciendo.

2) Desarrollador viene a ti, y tímidamente le pregunta "¿Tenemos copias de seguridad?"

Otra gran razón para evitar borrados en cascada es el rendimiento. Parecen como una buena idea hasta que tenga que eliminar 10.000 registros de la tabla principal, que a su vez tienen millones de registros en tablas secundarias. Dado el tamaño de esta cancelación, es probable que se bloquee por completo toda la mesa para horas quizá incluso días. ¿Por qué nunca arriesgarse a esto? Para la comodidad de pasar diez minutos menos tiempo a escribir las instrucciones delete adicionales para un registro elimina?

Además, el error se obtiene cuando se intenta eliminar un registro que tiene un registro hijo es a menudo una buena cosa. Te dice que no desea eliminar este registro robaba hay datos que es necesario que se perdería si lo hizo así. Eliminación en cascada que sólo seguir adelante y eliminar los registros secundarios que resultan en la pérdida de la información sobre los pedidos, por ejemplo si ha eliminado un cliente que tenía órdenes en el pasado. Este tipo de cosas puede estropear a fondo sus registros financieros.

Me dijeron también que las supresiones en cascada eran malas prácticas ... y por lo tanto nunca los usan hasta que me encontré con un cliente que los utiliza. Realmente no sé por qué no tenía que usar, pero pensaba que eran muy conveniente en no tener que codificar a cabo la eliminación de todos los registros FK también.

Así que decidí investigar por qué eran tan "malo" y por lo que he encontrado hasta ahora su no dar la impresión de ser algo problemático acerca de ellos. De hecho el único buen argumento que he visto hasta ahora es lo que HLGLEM se ha dicho sobre el rendimiento. Pero como estoy por lo general no borrando este número de registros Creo que en la mayoría de los casos su uso debe estar bien. Me gustaría escuchar de otros argumentos que otros pueden tener en contra de su uso para asegurarse de que he considerado todas las opciones.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top