Como seguramente sabes, debes evitar que entre basura en tu Base de Datos. ¿Y qué es basura? cualquier dato que está pero que no debería estar. Por ejemplo, el identificador de un producto que no existe o un precio de venta negativo cuando todos los precios sabemos que deben ser positivos (o en todo caso cero, pero nunca negativos).

Todas las validaciones que involucren a filas o columnas de una tabla pueden y DEBEN ser realizadas dentro de la Base de Datos en sus triggers o stored procedures.

Sin embargo, hay también validaciones que pueden y DEBEN ser realizadas afuera de la Base de Datos.

¿Cuáles son esas validaciones?

Todas aquellas que no requieran conocer el valor de una columna para saber si el dato que se quiere insertar o actualizar es correcto o incorrecto.

Por ejemplo, si sabemos que todos los precios de venta de nuestros productos deben ser positivos sí o sí, entonces a esa validación la hacemos en el código fuente del lenguaje de programación que estamos usando (Visual FoxPro, Visual Basic, C, C++, Delphi, Java, PHP, etc.)

Y por supuesto, volvemos a validar que el precio sea positivo dentro de nuestra Base de Datos, normalmente en un trigger o a veces en un stored procedure.

A esto se le llama doble validación.

¿Y por qué haríamos una doble validación?

Porque si la validación no la hacemos en nuestra aplicación y la hacemos solamente en nuestra Base de Datos puede ocurrir que encontremos un error y eso implicaría un tráfico innecesario en la red. Por ejemplo:

  • Desde nuestra aplicación queremos insertar una nueva fila a la tabla de PRODUCTOS
  • Entre los datos que pedimos que tenga la nueva fila está el precio de venta, el cual es negativo
  • Un trigger de la tabla de PRODUCTOS detecta que el precio de venta es negativo y devuelve una excepción
  • El Servidor le avisa al Cliente y éste a nuestra aplicación que ocurrió un error en el precio de venta

¿Y cuál es el problema de hacerlo así?

Que por la red estuvieron viajando el precio de venta negativo (para que la Base de Datos pudiera recibirlo) y luego la excepción con su correspondiente mensaje de error.

Y no eran necesarios esos viajes porque la validación de que el precio de venta no sea negativo pudo haberla realizado la aplicación antes de enviarlo por la red.

Si tu Base de Datos es usada por pocos usuarios y tu red tiene un buen ancho de banda entonces no se detectará una demora pero …. está mal, el concepto está errado, en todo momento debes preocuparte por conseguir que por la red viajen la menor cantidad posible de datos. Cuanto menos se use la red, mucho mejor. Y si tu Base de Datos está en Internet entonces lo anterior es muchísimo más importante porque Internet es una red lenta, mucho más lenta que tu red local.

Resumiendo, en todos aquellos casos en los cuales no es necesario conocer el valor de una columna para poder validar el dato la validación la deben realizar la aplicación y luego la Base de Datos también.

Por ejemplo: que el nombre no esté vacío, que la fecha no sea NULL, que el precio de venta no sea negativo, que el importe cobrado sea mayor que cero, etc. Todos estos datos y muchos más los puede validar la aplicación, no necesita enviarlos a la Base de Datos para descubrir que dichos datos no son aceptables.

Si tu aplicación funciona bien cuando hay pocos usuarios pero funciona desastrosamente cuando hay miles de usuarios algo hiciste muy mal. Y no deberías esperar a tener miles de usuarios para empezar a optimizar el tráfico en la red, mañana mismo o la semana que viene podrían proponerte que vendas una aplicación que usarán miles de personas a la vez y estarías desperdiciando un tiempo valioso en optimizar el tráfico en la red cuando desde el principio mismo podrías haberlo hecho correctamente.

Recuerda: por la red solamente deben viajar los datos que son imprescindibles, y cuantas menos veces viajen, mucho mejor.

.