Más allá de los lenjuajes de programación

Una aplicación típica de nuestros dias, opera en un entorno multi-usuario a través de una red y contempla el acceso a una base de datos.

Hasta principios de los 90's, las herramientas de programación más populares para escribir sistemas de bases de datos eran dBASE, Clipper y Fox Pro, sistemas estos que incluían sus propios lenguajes de programación como parte de su infraestructura. Un sistema creado, por ejemplo con Clipper, tenía la forma de un fichero ejecutable (con extension EXE) y un conjunto de ficheros con extension DBF donde recidían los datos. El programa ejecutable se encargaba de toda la funcionalidad del sistema, desde la comunicación con el usuario, hasta la manipulación de los ficheros DBF.

Los ficheros DBF se colocaban normalmente en un servidor de ficheros, mientras que los ejectutables eran copiados en cada máquina cliente. El hecho de que los ficheros DBF fueran manipulados directamente por los ejecutables desde las máquinas clientes, generaba un intenso tráfico en la red, disminuyendo notablemente el rendimiento del sistema a medida que el número de usuarios crecía.

La solución a este problema fue la adopción de una arquitectura Cliente/Servidor. En el lado servidor se coloca, no solo los ficheros que contienen los datos, sino el programa que los manipula directamente. Del lado cliente, se coloca el programa que interactúa con el usuario. Ambos programas se comunican a través de la red, pero ahora el tráfico es mucho menos intenso, pues solo hay que transmitir comandos de alto nivel; por ejemplo, si un usuario ordena poner la fecha de hoy en cuatro mil records, eso constituye una simple orden que es enviada a través de la red desde el programa cliente hasta el programa servidor; este último (que recide en la misma máquina donde están los ficheros de datos) se encarga de actualizar todos los records uno por uno, sin que ello acarrée tráfico adicional a través de la red.

La introducción de esta arquitectura condujo a estandarizar la comunicación entre el programa servidor y el programa cliente, surgiendo así un "lenguaje de interrogación de bases de datos" llamado SQL (Structured Query Language, ó Lenguaje Estructurado de Interrogación de baseses de datos). También surgieron sistemas comernciales de bases de datos muy sofisticados como DB2, Oracle y Microsoft SQL Server, que se instalan en el lado del servidor y pueden comunicarse con cualquier programa cliente que esté diseñado para entender el lenguaje SQL.

Esto dá tremenda flexibilidad a los programadores de sistema de bases de datos. Por una parte no tendrán que lidiar con los detalles de la manipulación directa de los ficheros de datos, y por otra parte, pueden escribir sus sistemas usando cualquier lenguaje de programación (Visual Basic, Delphi, C++, Java etc)... basta con instrumentar la comunicación con una base de datos comercial como Oracle ó Microsoft SQL Server, usando para ello el lenguaje de interrogación SQL.

Lo curioso, sin embargo, es que ahora un programador no puede conformarse con conocer un lenguaje de programación, sino que además, debe conocer un lenguaje de interrogación de bases de datos, es decir, SQL. Si el sistema se escribe para la Web, entonces el programador también debe conocer el "lenguaje de presentación" que se usa en la Web, que es HTML, y muy probablemente otros lenguajes que se usan en este entorno como javacript y vbscript.

En resumen, un programador de aplicaciones hoy en dia, trabaja a un alto nivel de abstracción respecto al hardware, pero al mismo tiempo tiene que ser experto no en uno, sino en varios lenguajes.