Las redes tienen una cantidad de tráfico limitada, los datos que van y vienen en ellas no son infinitos sino que tienen un límite. Cuanto mayor es la cantidad de usuarios que están enviando datos mayor es el tráfico en la red.

Cuando la red está saturada porque la cantidad de datos que se envían es mayor que la cantidad de datos que llegan a su destino todo se vuelve lento, en algunos casos extremadamente lento.

Nosotros debemos hacer todo lo posible para que la red no se sature porque una red saturada a nadie le beneficia y solamente puede causar problemas.

¿Y cómo lo hacemos?

Hay dos técnicas:

  1. Enviar solamente los datos necesarios
  2. Enviar los datos comprimidos

Enviar solamente los datos necesarios

Si llamamos a un stored procedure y éste nos devuelve una excepción porque alguno de sus parámetros de entrada es inválido eso significa que lo hicimos mal. La validación debimos haberla realizado antes de llamar al stored procedure. Por ejemplo, que el precio de venta sea positivo pudimos haber validado en nuestro programa fuente (en Visual FoxPro, Visual Basic, Delphi, C, C++, etc.) y nunca haber llamado al stored procedure. Lo mismo si el nombre no puede estar vacío, si la fecha debe ser posterior al 01/01/2012 o cualquier otro dato cuya validación podría haberse realizado afuera del stored procedure. Desde luego que en el stored procedure también podemos validar que el parámetro de entrada recibido sea el correcto pero si hicimos bien las cosas, siempre recibirá datos correctos.

En conclusión, el stored procedure siempre debe recibir datos ya validados, porque así evitamos el tráfico innecesario en la red que ocurriría si el stored procedure detecta que recibió datos incorrectos y devuelve una excepción para informarlo.

Enviar los datos comprimidos

En redes que tienen mucho tráfico y relativamente poco ancho de banda podemos comprimir los datos para que la cantidad de bytes enviados sea menor a la cantidad de bytes que se enviarían si no los hubiéramos comprimido.

Esto normalmente es útil para los parámetros de tipo caracter ya que los numéricos siempre ocupan poco espacio.

Lo que debemos cuidar cuando de datos numéricos se trata es de usar el tipo que más se adecua a nuestras necesidades. Ejemplos:

  • Si el número estará entre 0 y 255 podemos usar la función ASCII_CHAR() para guardarlo y la función ASCII_VAL() para recuperarlo. Ocupará 1 byte.
  • Si el número estará entre 0 y 32.767 debemos usar SMALLINT. Ocupará 2 bytes.
  • Si el número estará entre 0 y 2.147.483.647 debemos usar INTEGER. Ocupará 4 bytes.

Ejemplo: sería un desperdicio usar INTEGER para números que sabemos que estarán entre 0 y 100 ¿por qué? porque estaremos usando 4 bytes cuando podríamos haber usado solamente 1 byte. Cualquiera que entienda de bases de datos y vea eso enseguida descubrirá que no eres un buen profesional. Y no podrás negarlo, la prueba de que eres un mal profesional están a la vista.

Otro cuidado a tener en cuenta

Además de las dos técnicas anteriores hay otro punto muy importante y que  debes tener en cuenta si quieres una red fluida y es el siguiente: la red debe usarse exclusivamente con tus bases de datos. ¿Qué significa eso? que no debes permitir que la usen también con el Facebook, YouTube, navegar por Internet, descargar canciones o lo que sea. No. Jamás. Debes prohibir totalmente eso. Ningún ancho de banda será suficiente si los usuarios utilizan la red para el Facebook, YouTube y demás. Todo el trabajo que te tomaste en optimizar el tráfico en la red se habrá desperdiciado si los usuarios utilizan la red con otros fines. ¿Lo mejor que puedes hacer? especificar claramente en el contrato que firmaste con tu cliente que no garantizas velocidad si la red se usa para algo que no está relacionado con tus bases de datos.

Artículos relacionados:

La doble validación

El índice del blog Firebird21

Anuncios