¿Qué son los procedimientos almacenados y cuándo deberías usarlos?

Question

Accepted Answer

Un **procedimiento almacenado** es un conjunto de sentencias SQL (y lógica procedural) guardado en la base de datos y ejecutado por nombre. Ejecuta lógica *dentro* de la base de datos en lugar de en el código de la aplicación. Tienen beneficios reales pero también compensaciones significativas, por lo que cuándo usarlos es una verdadera decisión de diseño.

## Un procedimiento almacenado

```sql
-- define a procedure that encapsulates logic in the database
CREATE PROCEDURE transfer_funds(from_id INT, to_id INT, amount DECIMAL)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE accounts SET balance = balance - amount WHERE id = from_id;
  UPDATE accounts SET balance = balance + amount WHERE id = to_id;
  -- can include logic: conditionals, loops, error handling, transactions
END;
$$;

CALL transfer_funds(1, 2, 100);   -- execute by name
```

Un procedimiento almacenado agrupa SQL y lógica procedural (variables, condicionales, bucles, manejo de errores) en una rutina de base de datos nombrada y reutilizable. Las funciones son similares pero devuelven un valor.

## Posibles beneficios

```text
✓ Performance — runs IN the database (no round-trips for multi-step logic); precompiled
✓ Reduced network traffic — one call vs many queries from the app
✓ Reusability — shared logic callable from multiple applications/clients
✓ Security — grant EXECUTE on a procedure without granting table access; reduces
  injection surface (parameterized)
✓ Consistency — centralize critical logic so all clients use the same implementation
```

## Las compensaciones significativas (por qué muchos los evitan hoy)

```text
✗ Business logic in the DATABASE → harder to version-control, test, and maintain
  (logic split between app code and the database)
✗ Database-specific (PL/pgSQL vs T-SQL vs PL/SQL) → less portable, vendor lock-in
✗ Harder to debug than application code; weaker tooling
✗ Scaling — the database is often the hardest tier to scale; pushing logic there
  can increase its load
✗ Modern apps often prefer logic in the application layer (testable, portable, versioned)
```

## Cuándo usarlos

```text
✓ Performance-critical data-intensive operations (heavy multi-step DB logic, batch jobs)
✓ Logic that MUST be enforced at the DB level across multiple clients
✓ Reducing round-trips for operations involving many queries
✗ AVOID putting general business logic in procedures by default — modern practice
  usually favors the application layer (better testing, versioning, portability)
```

## Por qué es importante

Entender los procedimientos almacenados —incluyendo sus compensaciones— es un conocimiento valioso porque representan una verdadera opción arquitectónica con beneficios reales e inconvenientes reales, y saber *cuándo* usarlos (y cuándo no) refleja un criterio maduro.

Los procedimientos almacenados pueden ofrecer **beneficios de rendimiento** (ejecutar lógica de varios pasos dentro de la base de datos evita viajes de ida y vuelta en la red), reducción del tráfico de red, reutilización entre clientes, seguridad (otorgar ejecución sin acceso a tablas) y consistencia centralizada —haciéndolos apropiados para operaciones críticas de rendimiento intensivas en datos, procesamiento por lotes y lógica que debe aplicarse a nivel de base de datos en múltiples aplicaciones.

Sin embargo, entender las **compensaciones significativas** es igualmente importante y refleja la práctica moderna: poner lógica de negocio en la base de datos hace que sea más difícil controlar versiones, probar y mantener (dividiendo la lógica entre aplicación y base de datos), te vincula al lenguaje procedural de una base de datos específica (PL/pgSQL, T-SQL, PL/SQL —reduciendo la portabilidad), es más difícil de depurar y añade carga a la capa de base de datos (a menudo la más difícil de escalar).

Por estas razones, **el desarrollo de aplicaciones moderno a menudo favorece mantener la lógica de negocio en la capa de aplicación** (comprobable, portátil, versionada) en lugar de en procedimientos almacenados.

La idea clave es el **criterio de cuándo usarlos** —apropiado para necesidades específicas críticas de rendimiento o aplicación a nivel de base de datos, pero generalmente evitado como predeterminado para lógica de negocio.

Ya que los procedimientos almacenados son comunes en muchos sistemas (especialmente empresariales/heredados), y ya que entender tanto sus beneficios como sus compensaciones (y la inclinación moderna hacia la lógica de capa de aplicación) es lo que permite tomar decisiones arquitectónicas sólidas, entender los procedimientos almacenados es un conocimiento valioso de nivel senior que demuestra la capacidad de sopesar la lógica en el lado de la base de datos frente a la del lado de la aplicación —una consideración de diseño significativa y un tema que refleja madurez arquitectónica.