Los puntos de Quassnoi con respecto son válidos, pero vale la pena recordar que no todas las restricciones CHECK son iguales. En las siguientes pruebas, comparé el control REGEXP_LIKE() con otros dos controles "anticuados"; el primero convierte el valor en una cadena de ceros y luego realiza una comprobación de igualdad, y el segundo hace una comprobación de rango usando BETWEEN().
Las pruebas de "Reloj de pared" son sensibles a las condiciones ambientales (como el disparo de un punto de control), por lo que debemos ejecutarlas varias veces. Otra cosa a tener en cuenta es que el rendimiento puede variar de una versión a otra. Por ejemplo, estoy ejecutando 11g y la comprobación de expresiones regulares se ejecutó consistentemente en 9-10 segundos, lo que sugiere que Oracle lo ha optimizado considerablemente desde 10g. Por otro lado, las inserciones sin marcar se ejecutaron en 1.7 - 2 segundos ish, por lo que la expresión regular sigue siendo relativamente cara. El resto de los controles pesa alrededor de 2.5 - 3.0 segundos, lo que representa aproximadamente un 50% de integridad.
Si vale la pena pagar ese peaje realmente depende de cómo se siente acerca de sus datos. La experiencia dice que confiar en el cliente para hacer cumplir las reglas de datos significa inevitablemente que en algún punto las reglas se romperán. Ya sea porque un desarrollador omite aplicarlos o los elimina de la aplicación. O porque alguien adjunta a la base de datos una nueva aplicación cliente (por ejemplo, carga por lotes, servicio web) que no incluye esas reglas.
Por último, la mayoría de las aplicaciones no van a cargar un millón de filas a la vez. En comparación con el viaje de ida y vuelta de la red, los microsegundos requeridos para aplicar cheques a una sola inserción o carga son probablemente una carga trivial.
SQL> CREATE TABLE t_check (value VARCHAR2(50))
2/
Table created.
Elapsed: 00:00:00.01
SQL>
SQL> INSERT
2 INTO t_check
3 SELECT level
4 FROM dual
5 CONNECT BY
6 level <= 1000000
7/
1000000 rows created.
Elapsed: 00:00:01.68
SQL>
SQL> prompt Regex check
Regex check
SQL>
SQL> drop table t_check
2/
Table dropped.
Elapsed: 00:00:00.37
SQL> CREATE TABLE t_check (value VARCHAR2(50) NOT NULL
2 , CHECK(REGEXP_LIKE(value, '^[0-9]{1,10}$')))
3/
Table created.
Elapsed: 00:00:00.07
SQL>
SQL> INSERT
2 INTO t_check
3 SELECT level
4 FROM dual
5 CONNECT BY
6 level <= 1000000
7/
1000000 rows created.
Elapsed: 00:00:09.53
SQL>
SQL> prompt old fashioned "mask" check
old fashioned "mask" check
SQL>
SQL> drop table t_check
2/
Table dropped.
Elapsed: 00:00:00.59
SQL> CREATE TABLE t_check
2 (value VARCHAR2(50) NOT NULL
3 , CHECK(translate(lpad(value, 20, '0')
4 , '1234567890', '0000000000') = '00000000000000000000'))
5/
Table created.
Elapsed: 00:00:00.01
SQL>
SQL> INSERT
2 INTO t_check
3 SELECT level
4 FROM dual
5 CONNECT BY
6 level <= 1000000
7/
1000000 rows created.
Elapsed: 00:00:02.82
SQL>
SQL> prompt old fashioned "range" check
old fashioned "range" check
SQL>
SQL> drop table t_check
2/
Table dropped.
Elapsed: 00:00:00.39
SQL> CREATE TABLE t_check
2 (value VARCHAR2(50) NOT NULL
3 , CHECK(value between 1 and 1000000))
4/
Table created.
Elapsed: 00:00:00.01
SQL>
SQL> INSERT
2 INTO t_check
3 SELECT level
4 FROM dual
5 CONNECT BY
6 level <= 1000000
7/
1000000 rows created.
Elapsed: 00:00:02.23
SQL>
"Eso no es prudente, punto, especialmente si el costo de un total de un millón de insertos es tan insignificante como 25 segundos". Eso depende de la frecuencia con la que insertes un millón de registros, ¿verdad? Quassnoi señala que bajo ciertas circunstancias puede considerar no usar una restricción de verificación. Punto válido en mi humilde opinión. –
También depende del grado de control y responsabilidad que tenga sobre el software del cliente. Si usted es el dba que es responsable de la integridad total de los datos, pero no tiene control sobre lo que hacen las aplicaciones del cliente, entonces no tiene más remedio que ser paranoico y hacer cumplir cada regla que, si se rompe, se identificará el id. tomado como una falla para evitar la corrupción de datos. –
Si, por otro lado, escribe todas las aplicaciones así como también la base de datos, entonces depende de usted hacer cumplir las reglas, o posiblemente en ambos lugares. Una regla que casi siempre uso para hacer cumplir en ambos lugares es la regla no nula. No debería tomar un viaje redondo al servidor para descubrir que faltan algunos datos requeridos. Pero tampoco cuesta casi nada comprobarlo a nivel de la base de datos. –