Unidades Funcionales

Al igual que con otros aspectos de la implementación del estándar SQL, los detalles exactos varían un poco de RDBMS a RDBMS. En general:

• Las funciones no pueden controlar las transacciones.
• Las funciones devuelven valores; los procedimientos pueden modificar los parámetros designados OUT o INOUT que luego se puede leer en el contexto de llamada, pero nunca devuelve un resultado (excepto SQL Server).
• Las funciones se invocan desde las instrucciones SQL para realizar algún trabajo en los registros que se recuperan o almacenan, mientras que los procedimientos son independientes.

Más específicamente, MySQL también deshabilita la recursividad y algunas declaraciones SQL adicionales en las funciones. SQL Server prohíbe que las funciones modifiquen datos, ejecuten SQL dinámico y manejen errores. PostgreSQL no separó los procedimientos almacenados de las funciones hasta 2017 con la versión 11, por lo que las funciones de Postgres pueden hacer casi todo lo que hacen los procedimientos, salvo el control de transacciones.

Entonces, ¿cuál usar cuándo? Las funciones se adaptan mejor a la lógica que se aplica registro por registro a medida que se almacenan y recuperan los datos. Los flujos de trabajo más complejos que se invocan por sí mismos y mueven datos internamente son mejores como procedimientos.

Predeterminados y Generación

Incluso los cálculos simples pueden causar problemas si se realizan con la suficiente frecuencia o si existen múltiples implementaciones en competencia. Las operaciones en valores en una sola fila (piense en convertir entre unidades métricas e imperiales, multiplicar una tasa por horas trabajadas para subtotales de facturas, calcular el área de un polígono geográfico) se pueden declarar en una definición de tabla para abordar uno u otro problema. :

CREATE TABLE pythag (  a INT NOT NULL,  b INT NOT NULL,  c DOUBLE PRECISION NOT NULL    GENERATED ALWAYS AS (sqrt(pow(a, 2) + pow(b, 2)))    STORED);
 

La mayoría de los RDBMS ofrecen una opción entre columnas generadas "almacenadas" y "virtuales". En el primer caso, el valor se calcula y almacena cuando se inserta o actualiza la fila. Esta es la única opción con PostgreSQL, a partir de la versión 12, y MS Access. Las columnas generadas virtuales se calculan cuando se consultan como en las vistas, por lo que no ocupan espacio, pero se volverán a calcular con más frecuencia. Ambos tipos están estrictamente restringidos:los valores no pueden depender de la información fuera de la fila a la que pertenecen, no se pueden actualizar y los RDBMS individuales pueden tener limitaciones aún más específicas. PostgreSQL, por ejemplo, prohíbe particionar una tabla en una columna generada.

Las columnas generadas son una herramienta especializada. Más a menudo, todo lo que se necesita es un valor predeterminado en caso de que no se proporcione un valor en la inserción. Funciones como now() aparecen con frecuencia como valores predeterminados de columna, pero la mayoría de las bases de datos permiten funciones personalizadas e integradas (excepto MySQL, donde solo current_timestamp puede ser un valor predeterminado).

Tomemos el ejemplo bastante seco pero simple de un número de lote en el formato YYYYXXX, donde los primeros cuatro dígitos representan el año actual y los últimos tres un contador incremental:el primer lote producido este año es 2020001, el segundo 2020002, y así sucesivamente. . No hay un tipo predeterminado o una función integrada que genere un valor como este, pero una función definida por el usuario puede numerar cada lote a medida que se crea :

CREATE SEQUENCE lot_counter;CREATE OR REPLACE FUNCTION next_lot_number () RETURNS TEXT AS $$BEGIN  RETURN date_part('year', now())::TEXT ||    lpad(nextval('lot_counter'::REGCLASS)::TEXT, 2, '0');END;$$LANGUAGE plpgsql;CREATE TABLE lots (  lot_number TEXT NOT NULL DEFAULT next_lot_number () PRIMARY KEY,  current_quantity INT NOT NULL DEFAULT 0,  target_quantity INT NOT NULL,  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),  completed_at TIMESTAMPTZ,  CHECK (target_quantity > 0));
 

Referenciando datos en funciones

El enfoque de secuencia anterior tiene una debilidad importante (y al menos una menos importante ):llega el año nuevo, lot_counter seguirá teniendo el mismo valor que tenía el 31 de diciembre. Sin embargo, hay más de una forma de realizar un seguimiento de cuántos lotes se han creado en un año, consultando lots en sí mismo el next_lot_number La función puede garantizar un valor correcto después de que se transcurra el año.

CREATE OR REPLACE FUNCTION next_lot_number () RETURNS TEXT AS $$BEGIN  RETURN (    SELECT date_part('year', now())::TEXT || lpad((count(*) + 1)::TEXT, 2, '0')    FROM lots    WHERE date_part('year', created_at) = date_part('year', now())  );END;$$LANGUAGE plpgsql;ALTER TABLE lots  ALTER COLUMN lot_number SET DEFAULT next_lot_number();
 

Flujos de trabajo

Incluso una función de una sola declaración tiene una ventaja crucial sobre el código externo:la ejecución nunca deja la seguridad de las garantías ACID de la base de datos. Comparar next_lot_number arriba a las posibilidades de una aplicación cliente o incluso un proceso manual, ejecutando una instrucción SQL para contabilizar el número de lotes de este año hasta la fecha seguido de un segundo que inserta el nuevo lote. Si los pedidos se realizan lo suficientemente rápido, la cantidad de lotes podría cambiar debajo de usted entre el conteo y la inserción.

Los programas almacenados con varias declaraciones abren un inmenso espacio de posibilidades, ya que SQL incluye todas las herramientas que necesita para escribir código de procedimiento, desde el manejo de excepciones hasta puntos de guardado (¡incluso está completo con funciones de ventana y expresiones de tabla comunes!). Se pueden realizar flujos de trabajo de procesamiento de datos completos en la base de datos, lo que minimiza la exposición a otras áreas del sistema y elimina los viajes de ida y vuelta entre la base de datos y otros dominios que consumen mucho tiempo.

Gran parte de la arquitectura de software en general se trata de administrar y aislar la complejidad, evitando que se extienda a través de los límites entre los subsistemas. Si algún flujo de trabajo más o menos complicado implica extraer datos en el backend de una aplicación, secuencia de comandos o trabajo cron, digerirlos y agregarlos, y almacenar el resultado, es hora de preguntarse qué es lo que realmente requiere aventurarse fuera de la base de datos.

Como se mencionó anteriormente, esta es un área donde las diferencias entre los sabores de RDBMS y los dialectos de SQL pasan a primer plano. Una función o procedimiento desarrollado para una base de datos probablemente no se ejecutará en otra sin cambios, ya sea sustituyendo el TOP de SQL Server. para un LIMIT estándar cláusula o reelaborar completamente cómo se almacena el estado temporal en una migración empresarial de Oracle a PostgreSQL. Canonizar sus flujos de trabajo en SQL también lo compromete con su plataforma y dialecto actuales más a fondo que casi cualquier otra elección que pueda hacer.

Cálculos en consultas

Hasta ahora, hemos analizado el uso de funciones para almacenar y modificar datos, ya sea vinculados a definiciones de tablas o administrando flujos de trabajo de varias tablas. En cierto sentido, ese es el uso más poderoso que se les puede dar, pero las funciones también tienen un lugar en la recuperación de datos. Muchas herramientas que ya puede usar en sus consultas se implementan como funciones, desde funciones integradas estándar como count a extensiones como jsonb_build_object de Postgres , ST_SnapToGrid de PostGIS , y más. Por supuesto, dado que están más estrechamente integrados con la base de datos en sí, en su mayoría están escritos en lenguajes distintos a SQL (por ejemplo, C en el caso de PostgreSQL y PostGIS).

Si a menudo se encuentra (o cree que podría encontrarse) necesitando recuperar datos y luego realizar alguna operación en cada registro antes de que sea realmente Listo, ¡considere transformarlos al salir de la base de datos! ¿Proyectar una cierta cantidad de días hábiles a partir de una fecha? Generando una diferencia entre dos JSONB ¿los campos? Prácticamente cualquier cálculo que dependa únicamente de la información que está consultando se puede realizar en SQL. Y lo que se hace en la base de datos (siempre y cuando se acceda a ella de manera constante) es canónico en lo que se refiere a todo lo que se construya sobre la base de datos.

Hay que decirlo:si está trabajando con un back-end de aplicación, su kit de herramientas de acceso a datos puede limitar la cantidad de millas que obtiene al aumentar los resultados de las consultas con funciones. La mayoría de estas bibliotecas pueden ejecutar SQL arbitrario, pero aquellas que generan sentencias SQL comunes basadas en clases modelo pueden permitir o no personalizar la consulta SELECT liza. Las columnas o vistas generadas pueden ser una respuesta aquí.

Desencadenantes y Consecuencias

Las funciones y los procedimientos son bastante polémicos entre los diseñadores y usuarios de bases de datos, pero las cosas realmente despegue con gatillos. Un disparador define una acción automática, generalmente un procedimiento (SQLite permite solo una declaración), que se ejecutará antes, después o en lugar de otra acción.

La acción de inicio es generalmente una inserción, actualización o eliminación de una tabla, y el procedimiento desencadenante generalmente se puede configurar para que se ejecute para cada registro o para la declaración como un todo. SQL Server también permite activadores en vistas actualizables, principalmente como una forma de aplicar medidas de seguridad más detalladas; y él, PostgreSQL y Oracle ofrecen algún tipo de evento o DDL disparador que puede reaccionar a los cambios en la estructura de la base de datos.

Un uso común de bajo riesgo para los disparadores es como una restricción extra poderosa que evita que se almacenen datos no válidos. En todas las principales bases de datos relacionales, solo claves primarias y externas y UNIQUE las restricciones pueden evaluar información fuera del registro del candidato. No es posible declarar en una definición de tabla que, por ejemplo, solo se pueden crear dos lotes en un mes, y la solución de código y base de datos más simple es vulnerable a una condición de carrera similar a la del método de contar y luego establecer. lot_number sobre. Para hacer cumplir cualquier otra restricción que involucre a toda la tabla u otras tablas, necesita un disparador para ver fuera del alcance del registro:

CREATE FUNCTION enforce_monthly_lot_limit () RETURNS TRIGGERAS $$DECLARE current_count BIGINT;BEGIN  SELECT count(*) INTO current_count  FROM lots  WHERE date_trunc('month', created_at) = date_trunc('month', NEW.created_at);  IF current_count >= 2 THEN    RAISE EXCEPTION 'Two lots already created this month';  END IF;  RETURN NEW;END;$$LANGUAGE plpgsql;CREATE TRIGGER monthly_lot_limitBEFORE INSERT ON lotsFOR EACH ROWEXECUTE PROCEDURE enforce_monthly_lot_limit();
 

Una vez que comience a ejecutar DML y usando el control de flujo, es un salto saltar y saltar para iniciar secuencias de pasos mucho más complicadas y expandir el alcance para incluir aún otras tablas. Quizás la inserción de un registro en lots en sí mismo puede ser la operación final de un activador iniciado por una inserción en orders , sin ningún usuario humano o backend de aplicación habilitado para escribir en lots directamente. O como items se agregan a un lote, un disparador podría manejar la actualización de current_quantity e iniciar algún otro proceso cuando alcance la target_quantity .

Los activadores y las funciones pueden ejecutarse en el nivel de acceso de su definidor (en PostgreSQL, un SECURITY DEFINER declaración junto al LANGUAGE de una función ), que brinda a los usuarios limitados el poder de iniciar procesos de mayor alcance, y hace que validar y probar esos procesos sea aún más importante.

La pila de llamadas de activación-acción-activación-acción puede volverse arbitrariamente larga, aunque la verdadera recursividad en la forma de modificar las mismas tablas o registros varias veces en cualquier flujo de este tipo es ilegal en algunas plataformas y, en general, es una mala idea en casi todas las circunstancias. El anidamiento de disparadores supera rápidamente nuestra capacidad para comprender su alcance y sus efectos. Las bases de datos que hacen un uso intensivo de activadores anidados comienzan a pasar del ámbito de lo complicado al de lo complejo, y se vuelven difíciles o imposibles de analizar, depurar y predecir.

Programabilidad práctica

Los cálculos en la base de datos no solo se expresan de forma más rápida y concisa:eliminan la ambigüedad y establecen estándares. Los ejemplos anteriores liberan a los usuarios de la base de datos de tener que calcular los números de lote por sí mismos, o de preocuparse por crear accidentalmente más lotes de los que pueden manejar. Los desarrolladores de aplicaciones en particular a menudo han sido entrenados para pensar en las bases de datos como "almacenamiento tonto", que solo proporcionan estructura y persistencia, y por lo tanto pueden encontrarse, o peor aún, no darse cuenta de que lo están, articulando torpemente fuera de la base de datos lo que podrían hacer. más eficazmente en SQL.

La programabilidad es una característica injustamente pasada por alto de las bases de datos relacionales. Existen razones para evitarlo y más para limitar su uso, pero las funciones, los procedimientos y los disparadores son todas herramientas poderosas para limitar la complejidad que impone su modelo de datos en los sistemas en los que está integrado.