MySQL - Procedimientos y Funciones con parámetros opcionales

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");
    
    
    

    
p1
p2
    
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>");
    
    
    
    

    
p1
p2
    
Hello
Bye
    
    



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>");
    
    
    
    

    
p1
p2
p3
    
Hello
Bye
 
    
    


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).