Verificando si un string es un número válido

2 comentarios

A veces podemos necesitar saber si en una columna de tipo CHAR o VARCHAR se ha guardado un número válido.

¿Cómo lo conseguimos rápidamente?

Usando el predicado de comparación SIMILAR TO.

Ejemplo 1:

En la tabla de ALUMNOS tenemos una columna donde guardamos el número de la matrícula. Queremos verificar que solamente haya números válidos allí.

NUMEROS1

Captura 1. Si haces clic en la imagen la verás más grande

Listado 1.

SELECT
   ALU_MATRIC,
   ALU_NOMBRE
FROM
   ALUMNOS
WHERE
   ALU_MATRIC SIMILAR TO '[0-9]*'

NUMEROS2

Captura 2. Si haces clic en la imagen la verás más grande

Ejemplo 2:

Queremos saber cuales son los alumnos cuyo número de matrícula es incorrecto. Para ello solamente agregamos NOT, como podemos ver en el Listado 2.

Listado 2.

SELECT
   ALU_MATRIC,
   ALU_NOMBRE
FROM
   ALUMNOS
WHERE
   ALU_MATRIC NOT SIMILAR TO '[0-9]*'

NUMEROS3

Captura 3. Si haces clic en la imagen la verás más grande

Si lo que nos interesa es saber cuantos alumnos tienen número de matrícula correcto o número de matrícula incorrecto entonces en lugar de seleccionar la Matrícula y el Nombre usaríamos la función agregada COUNT().

Ejemplo 3:

En la tabla FACTURAS tenemos datos de las Facturas de venta.

NUMEROS4

Captura 4. Si haces clic en la imagen la verás más grande

Por alguna razón que no sabemos, la columna FAC_COBRAD es de  tipo VARCHAR, no es numérica. Por eso ahora queremos verificar que todos los números allí escritos sean números válidos.

Listado 3.

SELECT
   FAC_NUMERO,
   FAC_FECVEN,
   FAC_COBRAD
FROM
   FACTURAS
WHERE
   TRIM(FAC_COBRAD) SIMILAR TO '[\+\-]?[0-9]*.?[0-9]*' ESCAPE '\'

NUMEROS5

Captura 5. Si haces clic en la imagen la verás más grande

Explicando el patrón usado en SIMILAR TO

NUMEROS6

Conclusión:

Saber si en una columna de tipo CHAR o VARCHAR hay solamente números válidos puede ser muy útil muchas veces, en este artículo se mostró una técnica para realizar esa verificación.

Artículos relacionados:

Los predicados de comparación

Usando SIMILAR TO

El índice del blog Firebird21

El foro del blog Firebird21

 

Los niveles de usuarios

1 comentario

En un grupo de Whatsapp de Informática en el cual participo surgió una pregunta: ¿qué tan importante es el diseño visual de nuestras aplicaciones?

Y las respuestas posibles son:

  • Muy importante
  • Medianamente importante
  • Poco importante
  • Nada importante

¿Cuál es la respuesta correcta? Para conocerla debemos tener en cuenta lo siguiente: no todas las personas que utilizan nuestras aplicaciones están al mismo nivel. Veamos esto con mayor detalle.

Si la aplicación es muy sencilla, entonces es probable que sea utilizada por una sola persona: un contador, un médico, un abogado, un comerciante pequeño, etc.

Pero si la aplicación es más grande y estará en una red local o global, allí las cosas cambian: ya no es un solo usuario el involucrado, ya hay varios usuarios, quizás decenas, cientos, o miles de usuarios.

Pensemos en esto como en una pirámide organizacional: en el nivel más bajo están los operadores, cuya misión principal es cargar datos. En un nivel superior a ellos están los supervisores o capataces o jefes de sección. En un nivel superior a éstos se encuentran los gerentes o jefes de departamentos. Y en un nivel superior se encuentra el Presidente de la compañía o el propietario de la misma.

Y así como hay varios niveles de usuarios, éstos también tienen distintos intereses.

En el nivel más bajo, el de operador o introductor de datos, lo más importante es que la aplicación tenga un buen diseño: que no tenga colores chillones, que no emita sonidos fuertes o chirriantes, que las pantallas sean consistentes (por ejemplo, que todos los programas donde se introducen datos sean visualmente similares), que sea fácil y rápido introducir datos, que la aplicación les facilite la tarea sugiriéndoles los datos a introducir, etc.

En el nivel de supervisor el diseño visual de las pantallas es mucho menos importante. Ellos generalmente no cargan datos pero a veces quien sí carga datos le muestra algo en la pantalla. O se enfermó o se ausentó quien debía cargar los datos y como no se puede postergar esa carga el supervisor realiza la tarea. No es algo frecuente pero puede ocurrir.

En el nivel gerencial ya no se involucran en cargar datos así que las únicas pantallas que ven son las que muestran resultados, sea en forma de números y letras, sea en forma de gráficos.

En el nivel de Presidente o propietario de una empresa grande solamente interesan informes resumidos y gráficos también resumidos.

Como vemos, el diseño visual de nuestras pantallas de carga de datos varía en importancia dependiendo del nivel en el cual se encuentra una persona: para quien carga datos es extremadamente importante, para quien nunca ve esas pantallas no tiene importancia.

Al Presidente o propietario de la gran empresa lo que sí le importa es que los informes y gráficos estén actualizados y muestren datos correctos. Que el formulario donde se cargan  las ventas esté mal diseñado y que el operador debe hacer tres clic en los botones cuando con un mejor diseño podría haber eso solamente dos clic es lo que menos le importa. Para él, eso es una tontería que no merece ni siquiera un minuto de su tiempo.

Por el contrario, para el operador quien se encarga de cargar los datos, eso sí es muy importante, porque tarda más en realizar su tarea.

Entonces ¿debemos preocuparnos por el diseño visual de nuestras aplicaciones o no?

Después de todo, si quien firma nuestros cheques es el Presidente o propietario de la gran empresa ¿qué nos importa que las pantallas de cargas de datos sean un desastre siempre y cuando los informes y gráficos que provee nuestra aplicación sean muy buenos?

El tema es que para que nuestra aplicación sea exitosa: debemos tenerlos felices a todos.

Si los informes y gráficos finales son una maravilla pero las pantallas de introducción de datos son un desastre ¿qué ocurrirá? que los operadores se estarán quejando todo el día, diciendo que cargar datos es muy difícil, muy complicado, que hay que dar muchas vueltas, que las pantallas no son amigables, que no son consistentes, que no son inteligentes, que han visto otras aplicaciones mejores, que si tardan mucho en cargar datos es por culpa de esas pantallas mal diseñadas, etc.

Esas quejas al principio no surtirán efecto: la empresa gastó dinero en comprar la aplicación y no lo tirará a la basura por las quejas de los operadores. Pero esas quejas constantes no tardarán en calentarles las orejas a los supervisores, gerentes, y Presidente hasta que tomarán una decisión: o desechan esa aplicación problemática, o le piden al desarrollador que la modifique y cree unas pantallas de ingreso de datos que sean prácticas y funcionales.

En síntesis: el mal diseño visual de la aplicación la hizo fracasar.

Conclusión:

En una empresa u organización grande hay varios niveles de usuarios de nuestras aplicaciones y ellos tienen distintos intereses. En el nivel más bajo, el de quienes introducen datos, el diseño visual es extremadamente importante. En el nivel más alto tiene muy poca o ninguna importancia.

Pero si el nivel más bajo constantemente se está quejando eso hará que más temprano que tarde el primer nivel tome la decisión de adquirir otra aplicación o (en el mejor de los casos) pedirle al desarrollador que modifique su aplicación y la haga utilizable normalmente.

Un usuario descontento, esté en el nivel que esté, siempre es malo para nosotros. Ningún beneficio obtendremos de usuarios descontentos.

Así que, aunque debamos trabajar más, debemos tratar de tenerlos contentos a todos, porque: “cliente contento nos compra otra aplicación o nos recomienda con sus amigos”.

Y cliente descontento, bueno … ya te imaginas.

¿Cuál es la empresa más grande de software del mundo?

Microsoft

¿Y se preocupa por el diseño de sus programas?

Muchísimo. Tiene cientos de empleados que se dedican exclusivamente a eso. Así que si la empresa más grande del mundo considera que un buen diseño es muy importante ¿por qué tú no?

Cuando quitó el botón de Inicio del Windows, ¿qué sucedió? que recibió quejas de todos lados. ¿Y qué hizo Microsoft? Escuchó esas quejas y volvió a colocar el botón de Inicio.

¿Quieres que tu aplicación sea exitosa? Preocúpate por tenerlos contentos a todos tus usuarios, no solamente a quienes firmarán tus cheques.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

 

Firebird 3.0 Release 2 ya puede ser descargado

1 comentario

Ya está disponible para ser descargado y utilizado “casi en producción” el Firebird 3.0 Release 2.

Este Release 2 ya tiene todas las características y mejoras que tendrá la versión 3.0 final. Sin embargo, aún puede contener algunos errores pero éstos deberían ser pocos y no significativos.

Los enlaces para las descargas encontrarás en esta página:

Página de descarga de Firebird 3.0 Release 2

Y si descubres algún error, puedes informarlo en esta página:

Informe de errores encontrados en Firebird 3.0 Release 2

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

Usando CASE en la cláusula WHERE

8 comentarios

La cláusula WHERE del SELECT nos permite poner condiciones o sea filtrar los datos que obtendremos como resultado.

¿Cómo funciona la cláusula WHERE?

Mediante una comparación.

Cuando comparamos una cosa con otra cosa el resultado de esa comparación solamente puede ser verdadero o falso, no existe otra posibilidad.

Ejemplos:

CLI_CODIGO IS NULL     -- ¿El código del cliente es NULL?

CLI_CODIGO IS NOT NULL     --¿El código del cliente no es NULL?

EXTRACT(YEAR FROM ALU_FECING) = 2016     -- ¿El año en que ingresó el alumno es 2016?

PRD_PREVTA >10000     -- ¿El precio de venta del producto es mayor que 10000?

PRO_NOMBRE LIKE 'J%'     -- ¿El nombre del profesor empieza con la letra Jota?

Como ves, en todas las condiciones anteriores la respuesta puede ser afirmativa (verdadera) o negativa (falsa). No existe otra posibilidad.

Al usar un CASE en la cláusula WHERE de un SELECT debemos tener en cuenta ese punto. Siempre debemos comparar lo que devuelve el CASE con algo.

Listado 1.

SELECT
   *
FROM
   PERSONAS
WHERE
   CASE
      WHEN PER_SEXOXX = 1 THEN 'F'
      WHEN PER_SEXOXX = 2 THEN 'M'
   END = 'F'

Aquí el CASE solamente nos puede devolver una letra ‘F’ o una letra ‘M’, no hay otra posibilidad. Y comparamos lo que nos devolvió con la letra ‘F’ (eso es lo que hacemos después del END).

En otras palabras, la cláusula WHERE podría ser:

WHERE ‘F’ = ‘F’

o podría ser:

WHERE ‘M’ = ‘F’

¿Y qué haríamos si la columna PER_SEXOXX puede contener NULL?

Listado 2.

SELECT
   *
FROM
   PERSONAS
WHERE
   CASE
      WHEN PER_SEXOXX = 1 THEN 'F'
      WHEN PER_SEXOXX = 2 THEN 'M'
      ELSE 'X'
   END = 'F'

O sea que la cláusula WHERE devolverá una letra ‘X’ si la columna PER_SEXOXX es distinta de 1 y es distinta de 2. Por supuesto que devolver una ‘X’ no es obligatorio, puedes devolver cualquier otra letra que quieras.

Artículos relacionados:

Un error de concepto en la cláusula WHERE

Mostrando los resultados ordenados por cualquier criterio

El índice del blog Firebird21

El foro del blog Firebird21