Validando números de teléfono

2 comentarios

La operación más importante de todas en una Base de Datos es la introducción de datos válidos. Si los datos no son válidos entonces todo lo demás que hagamos (consultas, procesamientos) será incorrecto y no servirá, será inútil.

Un dato que a veces es importante validar y a veces no, es el número de teléfono.

Muchas veces el número de teléfono es simplemente informativo, está ahí pero prácticamente no se lo usa. Sin embargo en ocasiones es extremadamente importante que sea válido. Es para estos últimos casos que debemos asegurarnos de que pueda ser utilizado cuando se lo necesita.

¿Cómo validamos un número de teléfono?

Los números de teléfono completos siempre están compuestos de la siguiente forma:

  • Código del país o región
  • Código del área
  • Número local

Cada país o región grande tiene un número que lo identifica. Por ejemplo el código de Argentina es 54, el de Bolivia 591, el de Brasil 55, el de Estados Unidos 1, el de Paraguay 595, el de Puerto Rico 1787, etc. Para saber que se trata del código del país o región y no de un número local, se le antecede con el signo + o con doble cero. Es decir que escribir 00 ó escribir + es lo mismo, la misma cosa.

El código del área (el área puede ser una ciudad grande, un estado o provincia o departamento) siempre viene a continuación del código del país.

Y finalmente viene el número local.

Ejemplos:

+49 30 1234567 corresponde a Alemania (porque empieza con 49), Berlín (porque continúa con 30), y el 1234567 es el número de esa ciudad y país. También se lo podría haber escrito como. 00 49 30 1234567.

+54 351 1234567 corresponde a Argentina (porque empieza con 54), provincia de Córdoba (porque sigue con 351) y el 1234567 es el número de esa ciudad y de ese país al cual se desea llamar. También se lo podría escribir como: 00 54 351 1234567.

+595 21 123456 corresponde a Paraguay (porque empieza con 595), ciudad de Asunción (porque sigue con 21),  el 123456 es el número de esa ciudad y ese país al cual se desea llamar. También se lo podría escribir como: 00 595 21 123456.

¿Cómo diseñamos la tabla?

Es muy común que para guardar números de teléfono se defina una columna como CHAR o VARCHAR y luego una longitud suficientemente grande, como por ejemplo:

CREATE TABLE CLIENTES(
   CLI_IDENTI INTEGER,
   CLI_NOMBRE VARCHAR(80),
   CLI_TELEFO CHAR(20)
);

En este caso la columna CLI_TELEFO está definida como CHAR(20) y la mayoría de los diseñadores pueden creer que está bien. Sin embargo, no es lo correcto. ¿Por qué no es correcto? Porque los usuarios en la columna CLI_TELEFO podrían insertar datos así:

1234567

+595-21-1234567

021-1234567

21.1234567

00-595-21-1234567

Y si nuestra aplicación debe usar esos números para hacerles llamadas a los clientes será muy problemático conseguirlo. Lo correcto por lo tanto es:

CREATE TABLE CLIENTES(
   CLI_IDENTI INTEGER,         -- Identificador del Cliente
   CLI_NOMBRE VARCHAR(80),     -- Nombre del Cliente
   CLI_CODPAI CHAR(4),         -- Código del país al cual corresponde el teléfono
   CLI_CODARE CHAR(4),         -- Código del área dentro del país
   CLI_TELEFO CHAR(8)          -- Número de teléfono local
);

De esa manera nunca habrá confusión posible. Inclusive podríamos tener un trigger BEFORE INSERT OR UPDATE que verifique el código del país, algo como:

CREATE EXCEPTION 
   E_CODIGO_PAIS_INCORRECTO 'El código del país es incorrecto';
CREATE TRIGGER CLIENTES_BIU FOR CLIENTES
   ACTIVE BEFORE INSERT OR UPDATE
   POSITION 1
   AS
   BEGIN
 
      IF (NEW.CLI_CODPAI <> '54' AND NEW.CLI_CODPAI <> '595') THEN
         EXCEPTION E_CODIGO_PAIS_INCORRECTO;
 
   END;

Este trigger verifica que el país sea Argentina (código 54) o que sea Paraguay (código 595). Si los países fueran más de 2 entonces lo más conveniente sería tener una tabla, llamada por ejemplo PAISES en la cual se encontraran los códigos y los nombres de los países.

De todas maneras lo importante del trigger es que valida que el país ingresado sea solamente uno de los países válidos, evitando así que el usuario introduzca datos que no tienen sentido.

Análogamente a como se validó el código del país se podría validar el código del área. Algo como:

CREATE TRIGGER CLIENTES_BIU FOR CLIENTES
   ACTIVE BEFORE INSERT OR UPDATE
   POSITION 1
   AS
   BEGIN
 
      IF (NEW.CLI_CODPAI <> '54' AND NEW.CLI_CODPAI <> '595') THEN
         EXCEPTION E_CODIGO_PAIS_INCORRECTO;
 
      IF (NEW.CLI_CODPAI = '595') THEN BEGIN
         IF (NEW.CLI_CODARE <> '21' AND NEW.CLI_CODARE <> '61') THEN
            EXCEPTION E_CODIGO_AREA_INCORRECTO;
      END
 
   END;

Aquí, si el código del país es 595 el código del área debe ser 21 ó 61, ningún otro código de área será aceptado.

Conclusión:

Validar los números de teléfono a veces no es importante porque es un dato meramente informativo, pero hay ocasiones en que debemos asegurarnos de que sea un número válido. Para esos casos lo más conveniente es agruparlo según el código del país, del área, y número local. Esas tres columnas deben ser validadas para asegurarnos de que contienen números correctos.

Artículos relacionados:

Diseño de bases de datos. 1FN

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Usando IDENTIFICADORES y CÓDIGOS en nuestras tablas

Deja un comentario

Aunque un Identificador es distinto que un Código mucha gente los confunde, inclusive aún teniendo muchos años de experiencia informática siguen tratando a los Códigos como si fueran Identificadores y eso es incorrecto porque deberían usarse para tareas distintas.

Un Identificador como su nombre lo indica sirve para identificar a una fila, de tal forma que no exista confusión posible con alguna otra fila de la misma tabla. En general lo aconsejable es que sea numérico y autoincremental (1, 2, 3, 4, 5, 6, etc.)

Un Código también sirve para identificar a una fila, de tal forma que no exista confusión posible con alguna otra fila de la misma tabla. Puede ser numérico o alfanumérico (AB123, MMK01, SVB68, 575701238, etc.)

Como ves, ambos sirven para identificar a una fila de forma unívoca, o sea que no pueda confundirse con otra fila.

¿Cuál es la diferencia entre un Identificador y un Código?

Que el Identificador se usa de forma interna en la Base de Datos, para identificar unívocamente a cada fila de una tabla y para relacionar a dos (o más) tablas entre sí. Como son de uso interno los usuarios ni siquiera necesitan saber de que existen. Jamás deberías cambiar el valor de un Identificador, por ningún motivo.

El Código, en cambio, no debería usarse para relacionar a dos (o más) tablas entre sí, esa es la tarea de los Identificadores, no es la tarea de los Códigos. Esto implica que un Código:

a) Solamente existe en una tabla

b) Puede ser cambiado, no hay problema si cambia su valor (desde luego que si debe ser único no podrá estar repetido, pero esa es la única restricción)

En las pantallas y en los informes los usuarios no necesitan ver a los identificadores, recuerda que son para uso interno dentro de la Base de Datos. Los códigos sí pueden verlos, justamente para eso sirven, para ser visualizados por los usuarios.

IDENTI1

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

En la Captura 1 vemos las primeras columnas de una tabla llamada PRODUCTOS. En ella tenemos un Identificador llamado PRD_IDENTI y dos Códigos llamados PRD_CODIGO y PRD_CODBAR respectivamente. Este último significa “código de barras”.

También tenemos una tabla llamada MOVIMDET (detalles de los movimientos de los productos) cuyas primeras columnas son las siguientes:

IDENTI2

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

Para relacionar a ambas tablas se usa la columna MOV_IDEPRD (Identificador del producto), no se usa ni el Código del producto ni el Código de barras del producto, lo que se usa es su Identificador.

Si al consultar la tabla MOVIMDET queremos ver el Código o el Código de barras del producto, pues es muy fácil:

SELECT
   P.PRD_CODIGO,
   P.PRD_CODBAR,
   P.PRD_NOMBRE,
   D.MOV_CANTID,
   D.MOV_PRECIO,
   D.MOV_CANTID * D.MOV_PRECIO AS TOTAL
FROM
   MOVIMDET D
JOIN
   PRODUCTOS P
      ON D.MOV_CODSUC = P.PRD_CODSUC AND
         D.MOV_IDEPRD = P.PRD_IDENTI

Y listo, eso es todo, al relacionar a ambas tablas con un JOIN todas las columnas de la tabla PRODUCTOS están disponibles para ser mostradas o utilizadas en el SELECT.

Conclusión:

Aunque puedes usar a un Código como si fuera un Identificador eso no es lo correcto, los identificadores son para uso interno, los códigos son para uso externo. Los usuarios solamente necesitan ver a los códigos, ellos ni siquiera necesitan saber que existen los identificadores. El valor de un Código debería existir en solamente una tabla, en cambio el valor de un Identificador existirá en todas las tablas relacionadas. Jamás y por ningún motivo deberías cambiar el valor de un Identificador, en cambio puedes cambiar sin problemas el valor de un Código, todas las veces que quieras. En las pantallas y en los informes a los usuarios se les pueden mostrar los Códigos, pues para eso sirven, para ser vistos por los usuarios.

Como los identificadores son para uso interno no hay problema si tienen valores salteados (1, 2, 8, 24, 25, 39, etc.). Esto está muy bien, si cumplen con su misión de identificar a cada fila de la tabla de forma unívoca entonces no importa que falten algunos valores.

Como los códigos son para uso externo entonces quizás los usuarios prefieran verlos en secuencia correlativa (1, 2, 3, 4, 5, 6, 7, 8, etc.). A la Base de Datos no le afecta que estén en secuencia o que falten algunos números, porque dentro de la Base de Datos no se los utiliza, entonces podrías cambiar los códigos para que siempre se muestren en secuencia y jamás haya números faltantes. Pero cuidado con esto, a la Base de Datos no le importará que cambies o no cambies los valores de los códigos, porque nunca los usa. Pero a los usuarios sí que puede importarles porque si un Producto ayer tenía el código 123 y hoy ese mismo producto tiene el código 87, podrías complicarles la vida. Por lo tanto, el hecho de que se pueda cambiar los códigos para que siempre estén en secuencia no implica que se deba hacer eso.

En una Base de Datos bien diseñada jamás hay motivo para cambiar el valor de un Identificador. Aunque sí puede haber motivos para cambiar el valor de un Código (normalmente no debería cambiarse, pero si se cambia no le afecta a la Base de Datos, solamente le afecta a los usuarios).

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21