Parámetro VarChar de búsqueda, ¿es válido aumentar su tamaño para evitar error?

[[Al González]]

¡Hola!

Supongamos que tengo un SP (procedimiento almacenado) donde uno de sus parámetros es usado como valor a buscar dentro de una tabla. El parámetro, llamado P, está definido como VarChar (10), ya que el campo sobre el que busca el valor tiene la misma definición.

Dentro del SP, la cláusula Where de la sentencia SQL es:

Código SQL [-]
Where Campo Containing :P

(el operador usado también podría ser "=" u otros, en lugar de Containing)

Si ejecuto el procedimiento, dándole un valor de '1234567890A' para ese parámetro, el servidor, me arrojará el típico error "arithmetic exception, numeric overflow, or string truncation". Ya que el valor dado tiene once caracteres cuando el parámetro está definido con un tamaño de 10. Esto ocurre en Firebird, pero publico mi pregunta en esta sección por aplicarse, seguramente, a otras bases de datos también.

Entiendo que en estos casos se aconseja revisar previamente el valor dado para no sobrepasar la longitud máxima definida por el parámetro. Pero, a manera de prueba, hice otra cosa: aumenté el tamaño definido del parámetro a 11.

Resultado: el servidor ya no arroja ningún error, y el SP trabaja como se espera (por supuesto, no encuentra valores de once o más caracteres en un campo VarChar (10)). Probado en IB Expert con Firebird 1.5.

No estoy intentando asignar el valor dado a ningún campo, solamente lo uso para comparar, por lo que esta prueba que hice podría ser una solución alternativa en casos similares al mío. Resulta que el famoso valor dado es una cadena de caracteres que el usuario puede teclear dentro de un cuadro de texto para buscar dicho valor sobre diferentes campos. Y la aplicación por sí misma no conoce con precisión con qué parámetro(s) se va a buscar (aunque puede intervenir en ello, agregando algo de programación) ya que eso es determinado por otra capa del framework que utilizo.

Con esto he descubierto que si aumento, digamos, a 50, el tamaño de estos parámetros en todos los SPs de búsqueda. Ya sólo tendría que limitar la entrada en pantalla a un máximo de 50 caracteres para todos esos cuadros de texto, sin preocuparme más de cuál es el tamaño específico de cada campo donde se busca.

Mi pregunta es si, al hacer esto, ¿no estaría menguando significativamente el rendimiento del servidor a la hora de ejecutar esos SPs de búsqueda?

Quiero pensar que cuando Firebird encuentra una condición como

Código SQL [-]
Where Campo Containing :P

, y el valor de ese parámetro tiene una longitud mayor a la del campo, automáticamente descarta la fila que está comparando.

Comprendo que podría ser preferible revisar la longitud del valor antes de ejecutar el SP, para evitar que el servidor ejecute código inútil. Y quizá con esto esté ya contestándome respecto a lo que debo hacer. Pero viéndolo desde otro punto de vista, el procesamiento inútil del servidor podría ser prácticamente el mismo si buscamos un valor de longitud correcta pero que no existe en la tabla.

Quizá el argumento que termina de convencerme es: si el programa puede evitarle trabajo innecesario al servidor (sin causarle más trabajo), que lo evite. Creo que esta es una de esas cosas que debe hacer la "capa intermedia". La interfaz de usuario no tiene por qué validarlo puesto que carece de gran detalle de conocimiento respecto a los metadatos, y el servidor no debería hacer un procesamiento inútil que puede ser "autorizado" antes por alguien que conozca un poco más esos metadatos: la capa intermedia.

Entonces en la capa intermedia, en la parte del framework de clases donde concentro validaciones similares, agregaré una más para impedir la consulta al servidor cuando el valor String dado sobrepase el tamaño del parámetro VarChar en turno.

Este mensaje ha sido más que nada un pensamiento en voz alta, al más puro estilo Delphius (un abrazo, amigo ). Pero me gustaría conocer sus opiniones respecto a este tipo de problemas.

Saludos.

Al González.