Si usas procedimientos y funciones de base de datos en MySql o Sql, que reciben parámetros y que son llamados desde código back (por ejemplo, PHP), o desde cualquier otro lenguaje, habrás notado que, en más de una ocasión, si has decidido añadir un parámetro, o bien has creado un procedimiento o función alternativa (para que no se joda el código ya escrito) o has tenido que revisar todo el código back para añadir, aunque sea con vacío o null, el parámetro en cuestión.
Y habrás pensado... "ya podía tener SQL, al estilo de javascript, php y otros lenguajes, la posibilidad de crear un parámetro con un valor por omisión por si este no es suministrado", lo que viene a ser... un parámetro opcional.
Por ejemplo, vamos a utilizar un procedimiento muy sencillo que recibe dos parámetros de cadena, devolviendo sus valores.
CREATE PROCEDURE localdb.parameters_test(p1 varchar(10),p2 varchar(30) )
BEGIN
select p1,p2;
END
Si en este caso hacemos...
call parameters_test("hello","bye");
Si ahora cambiamos el procedimiento a...
CREATE PROCEDURE localdb.parameters_test(p1 varchar(10),p2 varchar(30),p3 varchar(10) )
BEGIN
select p1,p2,p3;
END
Pero no cambiamos la llamada, obtendremos un error.
¿Cómo podemos entonces usar procedimientos y funciones de bases de datos, donde, dentro de su código obtengamos parámetros opcionales, incluso de valores de tipo indefinido? Sí, ya sé que ahora la tendencia es usar el tipado de datos en todo momento, igual que desde 1998 al 2004 aproximadamente, se recomendaba usar las Foreign Keys para conservar la integridad de las tablas, mientras que después se puso de moda mantener la integridad en el código y no usar las claves relacionadas, o Foreign Keys. Y ahora muchos utilizan ya No-SQL para no definir una estructura rígida de base de datos.
Todo este tipo de prácticas son a elección del analista, que ha de tener en cuenta si se desea una integridad robusta, un desarrollo de código más ágil, y mil variables más. Como anécdota os contaré que muchos entendieron lo de "ahora no se lleva crear claves relacionadas/foreign keys" y terminaron por no usar índices clave. Sí. Ya imaginarás la de bases de datos que he tenido que indexar y reindexar porque, a cierto volumen de datos la consulta se hacía eterna. En SQL, usad claves, por favor!
Dicho esto... al grano.
Parámetros Opcionales en SQL/MySQL
Para "simular" y controlar los parámetros en funciones y procedimientos de base de datos, haremos uso del comando EXTRACTVALUE, que viene a ser como un "lector" o "intérprete" de valores XML. En el siguiente ejemplo básico, lo entenderás claramente.
CREATE PROCEDURE localdb.parameters_test(pAll varchar(300))
BEGIN
set @p1 = (select ExtractValue(pAll,"p1"));
set @p2 = (select ExtractValue(pAll,"p2"));
select @p1,@p2;
END
Call parameters_test("<p1>Hello</p1><p2>Bye</p2>");
Y si ahora cambiamos el procedimiento para aceptar un nuevo parámetro, no será necesario cambiar nada en el código back (o fuente o como quieras llamaro).
CREATE PROCEDURE localdb.parameters_test(pAll varchar(300))
BEGIN
set @p1 = (select ExtractValue(pAll,"p1"));
set @p2 = (select ExtractValue(pAll,"p2"));
set @p3 = (select ExtractValue(pAll,"p3"));
select @p1,@p2,@p3;
END
Call parameters_test("<p1>Hello</p1><p2>Bye</p2>");
Por supuesto, dentro del procedimiento o función, debes comprobar tanto el tipo, el valor y si existe o no el parámetro pasado para hacer que tu código sea comprensible y útil. Pero eso es a tu elección y a la de tu equipo (si lo hay).
Pero ... ¿dónde está? Bueno, sólo tienes que buscar en google "doodle ghost" para encontrarlo... pero, venga.. perezosos... os dejo el enlace de la página del doodle y del juego... a lo grande. Página Doodle Ghost de Google Directo a Ghost 2022
