Restricciones, transacciones o desencadenantes: ¿qué herramienta elegir?

Tres problemas, tres momentos de acción

Una restricción pregunta: ¿esta línea siempre respeta una regla? A transaction pregunta: ¿Estas operaciones deberían tener éxito o fracasar juntas? Un disparador pregunta: ¿deberíamos reaccionar automáticamente cuando ocurre un evento de datos?

La elección correcta comienza con esta diferencia. Utiliza un activador para todas las reglas de caché; Usar solo la aplicación permite que cada proceso vuelva a implementar los controles.

Restricción: evitar un estado no válido

NOT NULL requiere un valor, UNIQUE evita una repetición, CHECK verifica una condición y FOREIGN KEY garantiza la existencia de una relación. Estas reglas son declarativas y visibles en la estructura.

Para evitar un precio negativo, es preferible CHECK a un disparador: la regla es corta, atómica y entendida directamente por el SGBD.

CREATE TABLE produits (
  id_produit INTEGER PRIMARY KEY,
  prix NUMERIC NOT NULL CHECK (prix >= 0)
);

Transaction: Proteger una operación compuesta

Un pedido y su pago conciernen a dos mesas, pero forman una única intención comercial. BEGIN abre transaction, COMMIT confirma y ROLLBACK cancela. SAVEPOINT ofrece una devolución parcial en un transaction más largo.

Un transaction no reemplaza las restricciones: garantiza la atomicidad de las operaciones, mientras que las restricciones verifican cada estado propuesto.

BEGIN;
INSERT INTO commandes (id_commande, montant) VALUES (108, 120);
INSERT INTO paiements (id_commande, montant) VALUES (108, 120);
-- COMMIT si todo funciona; de lo contrario, ROLLBACK
COMMIT;

Desencadenante: reaccionar ante un evento

PostgreSQL separa la función del disparador y el disparador adjunto a la mesa. ANTIGUO contiene la línea antes de la modificación, NUEVO la línea propuesta. DESPUÉS DE UPDATE es adecuado para un historial de cambios ya aceptado.

ANTES puede modificar o rechazar NUEVO, pero una restricción sigue siendo más clara para una regla simple. FILA realiza la función para cada fila; STATEMENT lo ejecuta una vez para la declaración.

CREATE FUNCTION journaliser_prix() RETURNS trigger AS $$
BEGIN
  INSERT INTO historique_prix (id_produit, ancien_prix, nouveau_prix)
  VALUES (OLD.id_produit, OLD.prix, NEW.prix);
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER audit_prix
AFTER UPDATE OF prix ON produits
FOR EACH ROW EXECUTE FUNCTION journaliser_prix();

Cuándo no usar un disparador

Un disparador es particularmente adecuado para una auditoría o registro que debe aplicarse independientemente de quién llama. Incluso entonces, documente el efecto, prueba si hay errores y mida el costo.

• Una restricción expresa directamente la regla simple.
• La lógica debe ser visible en un servicio de aplicación y versionada con él.
• Una modificación masiva provocaría un procesamiento costoso por línea.
• El desencadenante corre el riesgo de modificar la misma tabla y crear una recursividad.
• El equipo carece de las pruebas y supervisión necesarias.

guía de elección rápida

Primero pregunte si está protegiendo una fila, un conjunto de operaciones o una reacción a un evento. Combine las herramientas cuando sus responsabilidades difieran: CHECK rechaza un precio no válido, un transaction agrupa la modificación y su pago, un disparador mantiene el antiguo precio aceptado.

No elija la longitud del código. Elija la regla de negocio, la visibilidad, el tiempo de ejecución, el comportamiento de error y el costo bajo carga.

Depende de ti

Combine estos casos: correo electrónico único, transferencia de débito/crédito, historial de direcciones, pedido vinculado a un cliente y creación de pedido/pago. Las respuestas esperadas son respectivamente restricción, transaction, posible desencadenante, clave externa y transaction.

La microcapacitación avanzada continúa en preparación hasta que un laboratorio PostgreSQL editable y reiniciable haya pasado sus pruebas de seguridad y solidez.