PL/SQL

PL/SQL (Procedural Language/SQL) es el lenguaje de programación procedural de Oracle Database. Extiende el SQL estándar con variables, condicionales, bucles, cursores y manejo de excepciones, y permite escribir lógica completa que se ejecuta dentro del motor de la base de datos como procedimientos almacenados, funciones, packages y triggers.

Su rasgo distintivo es dónde vive: el código PL/SQL se compila y ejecuta en el servidor de la base, al lado de los datos. Por eso, en empresas que llevan años operando con productos como Oracle E-Business Suite o con sistemas a medida sobre Oracle, es habitual que décadas de reglas de negocio (cálculo de precios, validaciones fiscales, cierres contables, interfaces entre módulos) estén implementadas en PL/SQL y no en la capa de aplicación.

Esa concentración de lógica tiene una consecuencia práctica: no se ve desde afuera. Un proyecto de integración o de migración que solo releva pantallas y servicios se pierde una parte central del sistema; entender qué hace el PL/SQL existente es parte obligatoria del diagnóstico antes de tocar un entorno Oracle con historia.

Qué se construye con PL/SQL

El código PL/SQL no vive en los archivos de una aplicación: se guarda y compila dentro de la propia base de datos, como objetos con nombre que cualquier proceso autorizado puede invocar. Los principales son:

• Procedimientos almacenados: rutinas que encapsulan una operación completa, por ejemplo registrar un cobro, actualizar el saldo del cliente y dejar el asiento contable en una sola transacción.
• Funciones: devuelven un valor y pueden invocarse desde consultas SQL; son típicas para cálculos reutilizables como impuestos, tipos de cambio o reglas de redondeo.
• Packages: agrupan procedimientos y funciones relacionados en un módulo con interfaz pública y cuerpo privado; son la unidad natural para organizar lógica de negocio grande.
• Triggers: se disparan solos ante un INSERT, UPDATE o DELETE sobre una tabla; se usan para auditoría, validaciones y sincronización entre tablas.

PL/SQL y SQL

No compiten: se complementan. SQL resuelve el acceso a los datos y PL/SQL le agrega la capacidad de programar procesos completos alrededor de esas consultas.

La última fila es la que pesa en los proyectos: una consulta SQL razonablemente estándar se puede mover entre motores con ajustes acotados, mientras que el código PL/SQL hay que convertirlo o reescribirlo si la empresa cambia de plataforma de datos.

Por qué la lógica vive en la base

Durante décadas, ejecutar la lógica junto a los datos fue la forma más eficiente y segura de construir sistemas transaccionales: sin viajes por la red, con commit y rollback nativos y con un único lugar donde auditar qué pasó. Productos como Oracle E-Business Suite llevan esa filosofía en su arquitectura, y los equipos internos la extendieron durante años con personalizaciones propias. El resultado típico en empresas de LatAm con ERP Oracle es que el corazón operativo, con su facturación, stock, liquidaciones e interfaces contables, es código PL/SQL acumulado que rara vez está documentado por completo y que suelen entender unas pocas personas.

Impacto en integraciones y migraciones

La lógica en la base es invisible desde afuera: un proceso ETL que escribe sobre una tabla puede disparar triggers sin saberlo, y una interfaz que esquiva la aplicación puede saltear validaciones que solo existen en un package. Por eso, antes de diseñar una integración con un sistema Oracle conviene relevar el PL/SQL involucrado y documentar qué hace cada objeto. En una migración a un ERP en la nube como Oracle Fusion Cloud el trabajo es mayor: la lógica existente se clasifica pieza por pieza para decidir qué queda cubierto por el estándar del nuevo producto, qué se reescribe como extensión o sobre una capa de integración y qué se retira porque el proceso cambió. Hacer ese relevamiento al principio del proyecto, y no cuando aparecen los errores, marca la diferencia entre una migración previsible y una llena de sorpresas.