Resumen de lo que he visto hasta ahora:
- A algunas personas no les gustan las cascadas.
Eliminación en cascada
- La eliminación en cascada puede tener sentido cuando la semántica de la relación puede implicar un exclusivo "es parte de " descripción. Por ejemplo, un registro de Línea de pedido es parte de su pedido principal, y las Líneas de pedido nunca se compartirán entre varios pedidos. Si el Pedido desapareciera, la Línea de pedido también debería hacerlo, y una línea sin Pedido sería un problema.
- El ejemplo canónico para Cascade Delete es SomeObject y SomeObjectItems, donde no tiene ningún sentido que exista un registro de elementos sin un registro principal correspondiente.
- No deberías no use Cascade Delete si está preservando el historial o usando una "eliminación suave/lógica" donde solo establece una columna de bits eliminada en 1/verdadero.
Actualización en cascada
- La actualización en cascada puede tener sentido cuando usa una clave real en lugar de una clave sustituta (columna de identidad/incremento automático) en las tablas.
- El ejemplo canónico para la actualización en cascada es cuando tiene una clave externa mutable, como un nombre de usuario que se puede cambiar.
- No deberías no utilice Actualización en cascada con claves que sean columnas de Identidad/incremento automático.
- La actualización en cascada se usa mejor junto con una restricción única.
Cuándo usar la cascada
- Es posible que desee obtener una confirmación adicional del usuario antes de permitir que una operación se realice en cascada, pero depende de su aplicación.
- La conexión en cascada puede causarle problemas si configura incorrectamente sus claves foráneas. Pero deberías estar bien si lo haces bien.
- No es aconsejable usar la cascada antes de comprenderla por completo. Sin embargo, es una función útil y, por lo tanto, vale la pena tomarse el tiempo para comprenderla.
