No escribirías una aplicación con funciones de 200 líneas de largo. Descompondría esas funciones largas en funciones más pequeñas, cada una con una única responsabilidad claramente definida.
¿Por qué escribir su SQL así?
Descomponga sus consultas, al igual que descompone sus funciones. Esto los hace más cortos, más simples, más fáciles de comprender, más fáciles de probar y más fáciles de refactorizar. Y le permite agregar "calces" entre ellos y "envoltorios" alrededor de ellos, tal como lo hace en el código de procedimiento.
¿Cómo haces esto? Al convertir cada cosa significativa que hace una consulta en una vista. Luego, redacta consultas más complejas a partir de estas vistas más simples, del mismo modo que compone funciones más complejas a partir de funciones más primitivas.
Y lo mejor es que, para la mayoría de las composiciones de vistas, obtendrá exactamente el mismo rendimiento de su RDBMS. (Para algunos no lo hará; ¿y qué? La optimización prematura es la raíz de todos los males. Primero codifique correctamente y luego optimice si es necesario).
A continuación, se muestra un ejemplo del uso de varias vistas para descomponer una consulta complicada.
En el ejemplo, debido a que cada vista agrega solo una transformación, cada una se puede probar de forma independiente para encontrar errores, y las pruebas son simples.
Aquí está la tabla base en el ejemplo:
create table month_value(
eid int not null, month int, year int, value int );
Esta tabla es defectuosa porque usa dos columnas, mes y año, para representar un dato, un mes absoluto. Aquí está nuestra especificación para la nueva columna calculada:
Lo haremos como una transformación lineal, de modo que se ordene igual que (año, mes), y tal que para cualquier tupla (año, mes) hay un único valor, y todos los valores son consecutivos:
create view cm_absolute_month as
select *, year * 12 + month as absolute_month from month_value;
Ahora lo que tenemos que probar es inherente a nuestra especificación, es decir, que para cualquier tupla (año, mes), hay uno y solo uno (mes_absoluto), y que (mes_absoluta) s son consecutivos. Escribamos algunas pruebas.
Nuestra prueba será una selectconsulta SQL , con la siguiente estructura: un nombre de prueba y una declaración de caso catenados juntos. El nombre de la prueba es solo una cadena arbitraria. La declaración del caso es solo case whendeclaraciones de prueba then 'passed' else 'failed' end.
Las declaraciones de prueba serán solo selecciones de SQL (subconsultas) que deben ser verdaderas para que la prueba pase.
Aquí está nuestra primera prueba:
--a select statement that catenates the test name and the case statement
select concat(
-- the test name
'For every (year, month) there is one and only one (absolute_month): ',
-- the case statement
case when
-- one or more subqueries
-- in this case, an expected value and an actual value
-- that must be equal for the test to pass
( select count(distinct year, month) from month_value)
--expected value,
= ( select count(distinct absolute_month) from cm_absolute_month)
-- actual value
-- the then and else branches of the case statement
then 'passed' else 'failed' end
-- close the concat function and terminate the query
);
-- test result.
Ejecutar esa consulta produce este resultado: For every (year, month) there is one and only one (absolute_month): passed
Siempre que haya suficientes datos de prueba en month_value, esta prueba funciona.
También podemos agregar una prueba para obtener suficientes datos de prueba:
select concat( 'Sufficient and sufficiently varied month_value test data: ',
case when
( select count(distinct year, month) from month_value) > 10
and ( select count(distinct year) from month_value) > 3
and ... more tests
then 'passed' else 'failed' end );
Ahora probemos si es consecutivo:
select concat( '(absolute_month)s are consecutive: ',
case when ( select count(*) from cm_absolute_month a join cm_absolute_month b
on ( (a.month + 1 = b.month and a.year = b.year)
or (a.month = 12 and b.month = 1 and a.year + 1 = b.year) )
where a.absolute_month + 1 <> b.absolute_month ) = 0
then 'passed' else 'failed' end );
Ahora coloquemos nuestras pruebas, que son solo consultas, en un archivo y ejecutemos ese script en la base de datos. De hecho, si almacenamos nuestras definiciones de vista en un script (o scripts, recomiendo un archivo por vistas relacionadas) para ejecutarlo en la base de datos, podemos agregar nuestras pruebas para cada vista al mismo script, de modo que el acto de (re -) la creación de nuestra vista también ejecuta las pruebas de la vista. De esa manera, ambos obtenemos pruebas de regresión cuando volvemos a crear vistas y, cuando la creación de la vista se ejecuta en producción, la vista también se probará en producción.