¿Qué versión de SQLcl estoy ejecutando?

Esto es algo que descubrí hace unos minutos por pura coincidencia y que no está documentado por lo que sé.

sqlcl_version

Pueden introducir version o show version y con eso obtienen la versión completa de SQLcl que están ejecutando.

Anuncios

SQLcl: Obteniendo la herramienta y requisitos para su funcionamiento

En el post anterior les conté acerca de esta nueva herramienta llamada SQLcl. En esta ocasión les voy a mostrar cómo obtenerla y lo que se requiere para empezar a utilizarla.

Requisitos

SQLcl es una aplicación desarrollada en Java lo que le permite ser ejecutada en múltiples sistemas operativos como Windows, Linux, OS X y Solaris.

En primer lugar, necesitamos asegurarnos de que tenemos instalado un JRE (Java Runtime Environment) que sea compatible con la herramienta. La versión 4.2 de SQLcl necesita Java 1.8 o superior. Pueden obtener la versión más reciente de Java aquí.

En caso de ya tener Java instalado en su computadora, pueden confirmar la versión ejecutando java -version en una ventana de comandos o terminal.

java

Obtener la herramienta

SQLcl se encuentra disponible en OTN (Oracle Technology Network) y necesitamos crear una cuenta antes de poder descargar cualquier software o participar en los foros de discusión. Una vez que tenemos una cuenta, podemos ir a la página de SQLcl y descargar la herramienta.

Como podrán notar, es tan solo un archivo zip de aproximadamente 16 MB. Lo único que hay que hacer es extraer el archivo zip en un nuevo directorio y todo está listo para empezar a trabajar.

Ejecutar SQLcl

Para ejecutar SQLcl debemos abrir una ventana de comandos o un terminal y dirigirnos al directorio que especificamos al extraer el contenido del archivo zip y posteriormente hasta el directorio bin. En mi caso yo puse SQLcl en C:\Users\gbalda\sqlcl4.2.0.16.260.1205.

location

Una vez que nos encontramos en el directorio bin, solamente debemos escribir sql y presionar ENTER para ejecutar la herramienta y poder ingresar nuestras credenciales para conectarnos a una base de datos.

connect

En el próximo post les voy a mostrar algunas formas de conectarse a la base de datos y cómo obtener información sobre la conexión.


SQLcl: Una interfaz de línea de comandos moderna

Esta es una lista que sirve como referencia para enlazar a los otros posts sobre SQLcl:

  1. OTN Appreciation Day: SQLcl.
  2. SQLcl: Obteniendo la herramienta y requisitos para su funcionamiento.
  3. ¿Qué versión de SQLcl estoy ejecutando?

OTN Appreciation Day: SQLcl

SQLcl es una nueva herramienta creada por el mismo equipo que desarrolla y mantiene SQL Developer y SQL Developer Data Modeler.

La idea central al crear esta herramienta fue el tomar la funcionalidad existente en SQL*PLUS y agregarle elementos modernos que encontramos en un IDE como SQL Developer. El resultado es una interfaz de línea de comandos moderna en la que podemos (entre otras cosas):

Exportar datos en distintos formatos (insert, json, xml, csv, etc). Esta es probablemente mi opción favorita.

sqlcl_sqlformat1

Examinar la historia de comandos y sentencias SQL que hemos ejecutado.

history1

Asociar un alias a una sentencia SQL que utilizamos con frecuencia para reducir la cantidad de caracteres que debemos escribir.

sqlcl_alias

En los próximos días empezaré una serie de posts mostrando las bondades de la herramienta. Mientras tanto aquí les dejo un enlace a las diapositivas de la presentación que realicé en el Oracle Open World 2016.


Mis Presentaciones en el Oracle Open World 2014

Un post muy breve para informarles de las dos presentaciones que voy a realizar en el Oracle Open World 2014.

Session ID:         UGF4482
Session Title:     “Getting Started with SQL Pattern Matching in Oracle Database 12c
Venue / Room:  Moscone South – 301
Date and Time:  9/28/14, 13:30 – 14:15

Session ID:          CON4493
Session Title:      “Regular Expressions in Oracle Database 101”
Venue / Room:   Moscone South – 303
Date and Time:   10/2/14, 13:15 – 14:00

No olviden de confirmar que las presentaciones sean en los salones que indico porque a veces hacen cambios de última hora.

Espero verlos por allá!


Expresiones de Tablas Comunes Recursivas al Rescate

Traducción del post original publicado en Noviembre 27 2013.

Las expresiones de tablas comunes recursivas han estado disponibles en Oracle desde la versión 11g R2 que fue lanzada por allá en el año 2009. Siempre las había considerado como una alternativa a la cláusula connect by para poder escribir consultas jerárquicas que siguieran el estándar ANSI, así que nunca me había tomado la molestia de revisar su funcionalidad en detalle.

Durante Kscope13, tuve la oportunidad de asistir a una sesión de Dominic Delmolino donde él mostró que las expresiones de tablas comunes recursivas pueden ser utilizadas para resolver otros tipos de problemas. Uno de los casos justamente es cuando necesitamos “generar un valor” y luego queremos hacer referencia a dicho valor en el siguiente registro de nuestra consulta.

No hace mucho tuve que trabajar en una consulta con un requerimiento similar. La idea básica es que tenemos un número variable de registros por cada cliente y para cada registro debemos establecer o calcular un nuevo valor (a la cual vamos a llamar VAL). La parte interesante está en que para algunos registros, VAL debe ser determinado utilizando el VAL que se encuentra en el registro anterior.

En primer lugar voy a crear una tabla y voy a insertar unos registros que ayuden a visualizar el problema.


SQL> CREATE TABLE RSF_TEST
 2 (
 3 ID_CLIENT NUMBER NOT NULL,
 4 DT_ELIG DATE NOT NULL,
 5 TP NUMBER NOT NULL,
 6 SRV_GRP NUMBER NOT NULL,
 7 SRV_CODE NUMBER NOT NULL,
 8 DT_ADMIT DATE NOT NULL,
 9 DT_DISCHARGE DATE NOT NULL
 10 );

Table created

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-11-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('01-05-2013', 'dd-mm-yyyy'), to_date('31-12-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-11-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-10-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('01-05-2013', 'dd-mm-yyyy'), to_date('31-12-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-10-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-09-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-09-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('01-05-2013', 'dd-mm-yyyy'), to_date('31-12-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-08-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('01-05-2013', 'dd-mm-yyyy'), to_date('31-12-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-08-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-07-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-07-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('01-05-2013', 'dd-mm-yyyy'), to_date('31-12-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-06-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('01-05-2013', 'dd-mm-yyyy'), to_date('31-12-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-06-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-05-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('01-05-2013', 'dd-mm-yyyy'), to_date('31-12-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-05-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-04-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('12-12-2012', 'dd-mm-yyyy'), to_date('30-04-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-04-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (615086545, to_date('01-03-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('07-03-2013', 'dd-mm-yyyy'), to_date('31-03-2014', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-03-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('12-12-2012', 'dd-mm-yyyy'), to_date('30-04-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-02-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('12-12-2012', 'dd-mm-yyyy'), to_date('30-04-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-01-2013', 'dd-mm-yyyy'), 13, 19, 12, to_date('12-12-2012', 'dd-mm-yyyy'), to_date('30-04-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-12-2012', 'dd-mm-yyyy'), 13, 19, 12, to_date('12-12-2012', 'dd-mm-yyyy'), to_date('30-04-2013', 'dd-mm-yyyy'));
1 row inserted

SQL> insert into RSF_TEST (ID_CLIENT, DT_ELIG, TP, SRV_GRP, SRV_CODE, DT_ADMIT, DT_DISCHARGE)
 2 values (525459313, to_date('01-03-2012', 'dd-mm-yyyy'), 13, 1, 1, to_date('18-01-2012', 'dd-mm-yyyy'), to_date('29-03-2012', 'dd-mm-yyyy'));
1 row inserted

SQL> commit;

Commit complete

SQL>

A continuación tenemos una versión simplificada del problema. La consulta original contiene más predicados y las sentencias CASE son un poco más complejas ya que deben cubrir una serie de posibles combinaciones de las columnas srv_grp, srv_code. Traté de limitar el código de forma que únicamente incluya lo necesario para mostrar cómo determinar VAL para los registros que existen en mi tabla.


WITH
clients AS
(
 SELECT
   id_client,
   dt_elig,
   tp,
   srv_grp,
   srv_code,
   dt_admit,
   dt_discharge,
   row_number() OVER (PARTITION BY id_client ORDER BY id_client, dt_elig) rn
 FROM rsf_test
),
results (id_client, dt_elig, tp, srv_grp, srv_code, dt_admit, dt_discharge, rn, val) AS
(
 SELECT
   id_client,
   dt_elig,
   tp,
   srv_grp,
   srv_code,
   dt_admit,
   dt_discharge,
   rn,
   CASE
     WHEN tp <> 14 AND srv_grp = 19 AND srv_code = 12 AND dt_elig BETWEEN dt_admit AND dt_discharge THEN 3
     WHEN tp <> 14 AND srv_grp = 19 AND srv_code = 12 AND dt_elig NOT BETWEEN dt_admit AND dt_discharge THEN 0
     WHEN tp <> 14 AND srv_grp IN (1,10) AND srv_code IN (1,3) THEN 0
   END val
 FROM clients
 WHERE
   rn = 1
 UNION ALL
 SELECT
   c.id_client,
   c.dt_elig,
   c.tp,
   c.srv_grp,
   c.srv_code,
   c.dt_admit,
   c.dt_discharge,
   c.rn,
   CASE
     WHEN c.tp <> 14 AND c.srv_grp = 19 AND c.srv_code = 12 AND p.val = 3 AND c.dt_elig BETWEEN c.dt_admit AND c.dt_discharge THEN 3
     WHEN c.tp <> 14 AND c.srv_grp = 19 AND c.srv_code = 12 AND p.val < 3 AND c.dt_elig BETWEEN c.dt_admit AND c.dt_discharge THEN p.val + 1
     WHEN c.tp <> 14 AND c.srv_grp IN (1,10) AND c.srv_code IN (1,3) AND p.val = 3 THEN 3
     WHEN c.tp <> 14 AND c.srv_grp IN (1,10) AND c.srv_code IN (1,3) AND p.val < 3 THEN p.val
     WHEN c.tp <> 14 AND c.srv_grp = 19 AND c.srv_code = 12 AND p.val = 3 AND c.dt_elig NOT BETWEEN c.dt_admit AND c.dt_discharge THEN 3
     WHEN c.tp <> 14 AND c.srv_grp = 19 AND c.srv_code = 12 AND p.val < 3 AND c.dt_elig NOT BETWEEN c.dt_admit AND c.dt_discharge THEN p.val
   END val
 FROM
   clients c,
   results p
 WHERE
   c.id_client = p.id_client
   AND c.rn = p.rn + 1
)
SELECT
  r.id_client,
  r.dt_elig,
  r.tp,
  r.srv_grp,
  r.srv_code,
  r.dt_admit,
  r.dt_discharge,
  --r.rn,
  r.val
FROM results r
ORDER BY
  r.id_client,
  r.dt_elig;

Como pueden ver, las expresiones de tablas comunes recursivas contienen dos consultas: La consulta anchor que sirve para generar el primer registro que luego es procesado por la consulta recursiva. Las dos consultas son combinadas mediante el operador UNION ALL.

Ahora veamos el resultado una vez que se ejecuta la consulta:


 ID_CLIENT DT_ELIG           TP    SRV_GRP   SRV_CODE DT_ADMIT  DT_DISCHA        VAL
---------- --------- ---------- ---------- ---------- --------- --------- ----------
 525459313 01-MAR-12         13          1          1 18-JAN-12 29-MAR-12          0
 525459313 01-DEC-12         13         19         12 12-DEC-12 30-APR-13          0
 525459313 01-JAN-13         13         19         12 12-DEC-12 30-APR-13          1
 525459313 01-FEB-13         13         19         12 12-DEC-12 30-APR-13          2
 525459313 01-MAR-13         13         19         12 12-DEC-12 30-APR-13          3
 525459313 01-APR-13         13         19         12 12-DEC-12 30-APR-13          3
 525459313 01-MAY-13         13         19         12 01-MAY-13 31-DEC-13          3
 525459313 01-JUN-13         13         19         12 01-MAY-13 31-DEC-13          3
 525459313 01-JUL-13         13         19         12 01-MAY-13 31-DEC-13          3
 525459313 01-AUG-13         13         19         12 01-MAY-13 31-DEC-13          3
 525459313 01-SEP-13         13         19         12 01-MAY-13 31-DEC-13          3
 525459313 01-OCT-13         13         19         12 01-MAY-13 31-DEC-13          3
 525459313 01-NOV-13         13         19         12 01-MAY-13 31-DEC-13          3
 615086545 01-MAR-13         13         19         12 07-MAR-13 31-MAR-14          0
 615086545 01-APR-13         13         19         12 07-MAR-13 31-MAR-14          1
 615086545 01-MAY-13         13         19         12 07-MAR-13 31-MAR-14          2
 615086545 01-JUN-13         13         19         12 07-MAR-13 31-MAR-14          3
 615086545 01-JUL-13         13         19         12 07-MAR-13 31-MAR-14          3
 615086545 01-AUG-13         13         19         12 07-MAR-13 31-MAR-14          3
 615086545 01-SEP-13         13         19         12 07-MAR-13 31-MAR-14          3
 615086545 01-OCT-13         13         19         12 07-MAR-13 31-MAR-14          3
 615086545 01-NOV-13         13         19         12 07-MAR-13 31-MAR-14          3

22 rows selected.

En éste ejemplo en particular, la consulta anchor asigna ya sea un 0 o un 3 para VAL en el primer registro y de ahí la consulta recursiva evalúa si VAL debería incrementarse o permanecer estático en cada uno de los siguientes registros. La idea es tener acceso a VAL de la iteración previa para poder determinar el nuevo valor en la iteración actual.


Tratando de validar direcciones de correo electrónico usando expresiones regulares

Traducción del post original publicado en Julio 10 2013.

Después de mi presentación en Kscope13, uno de los asistentes se me acercó a preguntarme si alguna vez había tratado de validar direcciones de correo electrónico utilizando expresiones regulares. Ésta persona no había escuchado sobre expresiones regulares antes de la presentación y me contó que en su trabajo estaba tratando de crear una función PL/SQL (la cual se estaba volviendo muy compleja) que se encargara de dicha funcionalidad. Le ofrecí ver si podía lograr algo y escribir una entrada en el blog.

Después de algunos intentos y de entender que no es una tarea sencilla, me decidí por la siguiente expresión regular: ^[a-z0-9._-]+@[a-z0-9.-]+\.[a-z]{2,3}$

En éste caso, yo considero que una dirección de correo electrónico es correcta si la misma empieza con una secuencia de caracteres que puede incluir cualquier letra o dígito, el punto, el guión o el guión bajo, a continuación el símbolo @ seguido por una secuencia de caracteres que puede incluir cualquier letra o dígito, el  punto o el guión y finalizando con un punto seguido de una secuencia de caracteres que contiene entre dos y tres letras.

Está claro que una dirección de correo electrónico puede contener otros caracteres; pero decidí utilizar aquellos que se ven con mayor frecuencia. No hay que olvidar que ésta expresión regular solamente considera letras minúsculas y que podemos pasar un parámetro a las funciones regexp en SQL para indicar que deseamos validar direcciones sin importar si las letras son mayúsculas o minúsculas.

Veamos cómo funciona todo utilizando datos que se encuentran en una tabla de clientes:

SQL> select * from clients;

NAME_CLIENT               PHONE                EMAIL
------------------------- -------------------- ------------------------------
FOUNTAIN,VICKIE L                              Vickie.L.Fountain@mail.com
ORTIZ,GENOVEVA M                               123ortiz.gmail.com
MALDONADO,TERESA                               teresa-maldonado@amazon.store
BARAJAS-RAMIREZ,AMY
SERRANO,GRACE
BALDA GALO                (512) 254-1694       galo@email.mydomain.net

6 rows selected.

Se puede observar que las direcciones de correo que siguen el patrón de la expresión regular pertenecen a los registros 1 y 6 y que las direcciones de correo en los registros 2 y 3 no siguen el patrón.

Podemos utilizar la siguiente sentencia SQL para encontrar los registros que siguen el patrón definido en la expresión regular:

SQL> select *
  2 from clients
  3 where regexp_like (email,'^[a-z0-9._-]+@[a-z0-9.-]+\.[a-z]{2,3}$','i');

NAME_CLIENT               PHONE                EMAIL
------------------------- -------------------- ------------------------------
FOUNTAIN,VICKIE L                              Vickie.L.Fountain@mail.com
BALDA GALO               (512) 254-1694        galo@email.mydomain.net

2 rows selected.

Se debe notar que la primera dirección de correo es considerada correcta a pesar de que no se definieron caracteres en mayúsculas en la expresión regular. Ésto ocurre debido al uso del parámetro ‘i’ en la función, lo que le indica que no importa si los caracteres están en mayúsculas o minúsculas.

Ahora busquemos los registros que no siguen el patrón definido en la expresión regular:

SQL> select *
  2 from clients
  3 where not regexp_like (email,'^[a-z0-9._-]+@[a-z0-9.-]+\.[a-z]{2,3}$','i');

NAME_CLIENT               PHONE                EMAIL
------------------------- -------------------- ------------------------------
ORTIZ,GENOVEVA M                               123ortiz.gmail.com
MALDONADO,TERESA                               teresa-maldonado@amazon.store

2 rows selected.

En éste caso, la primera dirección de correo no sigue el patrón definido en la expresión regular ya que falta la @. La segunda dirección utiliza un dominio formado por cuatro letras pero el patrón que estamos tratando de validar lo limita a dos o tres letras.

En resumen, éstos ejemplos muestran cómo empezar a realizar validaciones de direcciones de correo electrónico usando expresiones regulares. El patrón utilizado es bien básico, no es perfecto y puede ser mejorado; pero siempre dependerá del formato (o los formatos) de direcciones de correo electrónico que se desee validar y la complejidad de su representación.

Espero que les sea de ayuda.