¿Eliminaciones/actualizaciones en cascada utilizando JPA o dentro de la base de datos?

Question

El rendimiento es clave:¿Es mejor realizar eliminaciones/actualizaciones en cascada dentro de la base de datos o dejar que Hibernate/JPA se encargue de ello?

¿Esto afectará la capacidad de consultar los datos si las cascadas están dentro del DBMS?

Estoy usando HSQLDB si eso importa.

Answer 1

En el caso de las actualizaciones en cascada, usted simplemente no puede hacerlo en el espacio de aplicación si tiene restricciones de clave externa en la base de datos.

Ejemplo: supongamos que tiene una tabla de consulta para los estados de Estados Unidos, con una clave principal de la abreviatura de dos letras. Entonces usted tiene una mesa para las direcciones de correo que hace referencia a ella. Alguien le dice que por error se dio Montana la abreviatura "MO" en lugar de "MT" por lo que hay que cambiar en la tabla de búsqueda.

CREATE TABLE States (st CHAR(2) PRIMARY KEY, state VARCHAR(20) NOT NULL);
INSERT INTO States VALUES ('MO', 'Montana');

CREATE TABLE Addresses (addr VARCHAR(20), city VARCHAR(20), st CHAR(2), zip CHAR(6),
  FOREIGN KEY (st) REFERENCES States(st));
INSERT INTO Addresses VALUES ('1301 East Sixth Ave.', 'Helena', 'MO', '59620');

Ahora se van a solucionar el error, sin la ayuda de cambios en cascada por el lado de la base de datos. A continuación se muestra una prueba de uso de MySQL 5.0 (asumen que no existen registros de Missouri, que en realidad hace uso de la abreviatura "MO").

UPDATE States SET st = 'MT' WHERE st = 'MO';

ERROR 1451 (23000): Cannot delete or update a parent row: 
 a foreign key constraint fails (`test/addresses`, 
 CONSTRAINT `addresses_ibfk_1` FOREIGN KEY (`st`) REFERENCES `states` (`st`))

UPDATE Addresses SET st = 'MT' WHERE st = 'MO';

ERROR 1452 (23000): Cannot add or update a child row: 
 a foreign key constraint fails (`test/addresses`, 
 CONSTRAINT `addresses_ibfk_1` FOREIGN KEY (`st`) REFERENCES `states` (`st`))

UPDATE Addresses JOIN States USING (st)
SET Addresses.st = 'MT', States.st = 'MT'
WHERE States.st = 'MO';

ERROR 1451 (23000): Cannot delete or update a parent row: 
 a foreign key constraint fails (`test/addresses`, 
 CONSTRAINT `addresses_ibfk_1` FOREIGN KEY (`st`) REFERENCES `states` (`st`))

No se consulta la zona de aplicación puede resolver esta situación. Usted necesita actualizaciones en cascada en la base de datos con el fin de realizar la actualización en ambas tablas atómicamente, antes de que se cumpla la restricción de integridad referencial.

Answer 2

1. La corrección es clave

Dicho esto, en este caso la corrección y el rendimiento es casi seguro que ir de la mano desde la base de datos es el lugar adecuado para poner (y hacer cumplir) restricciones duras en la integridad de los datos y que será apreciablemente más rápido en una grave supresión en cascada, ya que:

• Evita múltiples idas y vueltas a la base de datos
• reduce el tiempo durante el cual una transacción puede tener que ser realizada
• Puede utilizar las estructuras internas relacionadas con el índice de clave externa para hacerlo sin tener que entrenar / reutilización de un plan de ejecución

Answer 3

ACTUALIZAR: Parece que una pregunta similar ya fue respondida aquí. ¿Cuándo y por qué utilizar Cascading en SQL Server?

OMI respuesta correcta a tu pregunta será como siempre "Eso depende".Si está utilizando una base de datos como almacenamiento de información confidencial (p. ej.financiero, médico, etc.), o si alguien más fuera de su aplicación podría tener acceso a la base de datos, votaré por el enfoque Hibernate/JPA.Si su base de datos es para iniciar sesión (p. ej.tráfico del sitio web, etc.) o si está desarrollando software con una base de datos integrada, puede utilizar operaciones en cascada con relativa seguridad.

2.En la mayoría de los casos votaré por el enfoque Hibernate/JPA porque es más manejable y predecible.

Te cuento una historia.Hace algún tiempo un país joven decidió cambiar su moneda nacional (sucedió con los países jóvenes).Un par de años más tarde, un nuevo administrador de bases de datos vio en una fila de la tabla de divisas una moneda obsoleta y decidió eliminarla (quién sabe por qué).¿Adivina qué pasó?El 30 % de la base de datos se eliminó debido a operaciones de eliminación en cascada.En mi opinión, con las operaciones en cascada, debes tener mucho cuidado con todas las declaraciones que eliminas/actualizas de una mano y pierdes el poder de las restricciones (es decir,claves externas) para la validación de la base de datos por otra parte.