Hasta ahora, todo lo que hemos hecho en esta serie de artículos podíamos realizarlos con las tablas .DBF, nativas del Visual FoxPro. Eso está muy bien y podríamos quedarnos allí porque como habrás comprobado si pusiste en práctica los ejemplos con tus propias tablas, hay una muy notoria ganancia en velocidad. Escribes menos y obtienes los resultados mucho más rápidamente. Está muy bueno eso ¿verdad?. Pero no nos quedaremos allí sino que daremos un gran salto hacia adelante y nos adentraremos en una tecnología muy distinta a la tradicionalmente usada en Visual FoxPro pero que a su vez es extremadamente poderosa. Su nombre es Cliente/Servidor y es más o menos el equivalente a que un jugador de fútbol de un club sudamericano de mediano porte vaya a jugar al Barcelona de España o al Real Madrid o algo así. Es totalmente otro nivel de juego.
Entonces, ¿de qué se trata Cliente/Servidor?
Lo primero que debes saber es que esta es una metodología para acceder a los datos desde varias computadoras, en otras palabras, desde una red de computadoras. Aunque puedes hacer aplicaciones Cliente/Servidor que sean monousuario no fue pensado para eso sino para aplicaciones multiusuario.
En las aplicaciones antiguas (o sea, las tradicionales del VFP) los programas “tocaban” físicamente a los datos, o sea que por un lado estaba el programa, por el otro lado estaban los datos que se guardaban dentro de los archivos y no había algo entre ellos que los separara.
Programa <——–> Archivo de datos
Esto funcionaba, pero con muuuchos problemas potenciales, por ejemplo un usuario estaba modificando un registro que otro usuario también estaba modificando. O un usuario estaba borrando un registro que otro usuario necesitaba en su informe. Eso causaba muchos inconvenientes. Mientras no había algo mejor los usuarios debían conformarse con eso … pero ahora tenemos Cliente/Servidor.
¿Cómo funciona Cliente/Servidor?
En esta metodología los programas jamás “tocan” físicamente a los datos, aunque quieran hacerlo no podrán, es totalmente imposible. En lugar de eso, los programas se comunican con el Cliente, el Cliente le envía una petición al Servidor, y es el Servidor quien procesa esa petición y le envía la respuesta al Cliente y el Cliente se la envía de regreso al programa.
Programa —–> Cliente —–>Servidor
Servidor —–> Cliente —–> Programa
Como ves, el camino es mucho más largo pero también es muchísimo más seguro y confiable. El Cliente es el intermediario. Nada puede hacerse sin él.
Entonces, el Servidor se instala en una computadora. ¿En cuál computadora? En la computadora donde estarán alojadas todas las bases de datos.
El Cliente se instala en todas las demás computadoras, o sea en las computadoras que usarán los usuarios.
¿Y cómo se comunica el Cliente con el Servidor, y viceversa? Para que la comunicación entre ellos sea posible se necesita de una canal de comunicación. Hay muchos canales de comunicación, entre ellos: ADO, JDBC, ODBC, .NET, .PYTHON, etc. El más usado es el ODBC, pero tú puedes optar por cualquier otro, si así lo prefieres.
Cuando un programa necesita algo se lo pide al Cliente y éste se lo pide al Servidor. ¿Qué puede necesitar un programa? Veamos algunos ejemplos:
- Grabar la venta que corresponde a la Factura Nº 12345, con fecha de hoy, le vendimos a Juan Pérez y el monto de la venta fue de 1.250 dólares
- Grabar la cobranza que hoy le hicimos a María Benítez, según el Recibo Nº 785 y por un monto de 420 dólares
- Cambiar el precio de venta de los monitores Toshiba de 21″, el nuevo precio es 100 dólares
- Ver todas las ventas que hicimos el mes pasado
- Ver los nombres de todos los vendedores que hoy hicieron ventas por más de 500 dólares
En todos estos casos el programa se lo pide al Cliente, el Cliente se lo pide al Servidor y el Servidor trata de cumplir con el pedido. Si pudo cumplir se lo indica al Cliente enviándole un número 1. Si no pudo cumplir le envía el número -1. Y si aún no terminó de procesar el pedido le envía un 0 (cero) y así el Cliente sabe que el Servidor todavía está trabajando.
Por lo tanto, cuando recibe un 1 el Cliente sabe que su petición tuvo éxito. Y si recibe un -1 el Cliente sabe que su petición falló. Súper fácil ¿verdad?
Si la petición tuvo éxito entonces el Cliente recibe un “cursor”. ¿Y qué es un cursor? ya lo sabes, porque ya lo hemos descrito en artículos anteriores de esta serie. Un cursor es una tabla de memoria, una tabla virtual, una copia del contenido que hay en el Servidor.
Eso significa que si modificas el cursor la Base de Datos ni se entera, su contenido queda exactamente igual a como estaba antes. ¿Por qué? porque el cursor es una copia de lo que está dentro de la Base de Datos (es como fotocopiar un libro, si escribes sobre la fotocopia el libro original continúa igual, allí no verás lo que escribiste en la fotocopia. En Cliente/Servidor siempre trabajas con fotocopias y jamás puedes tocar al libro original).
Resumiendo:
- El Servidor se instala en una sola computadora (en la que se guardarán todas las bases de datos)
- El Cliente se instala en muchas computadoras (en las que trabajarán los usuarios)
- Para que el Cliente y el Servidor puedan comunicarse entre sí se necesita de un canal de comunicación entre ellos (por ejemplo el driver ODBC)
- El Cliente envía peticiones al Servidor, el Servidor procesa esas peticiones y luego le envía el resultado al Cliente
- El Cliente sabe que su petición tuvo éxito si recibe como respuesta el número 1. Si la respuesta es -1 entonces la petición falló. Si la respuesta es 0 entonces el Servidor aún continúa procesando los datos
- Si el Cliente recibió un 1 porque la petición tuvo éxito entonces también recibe un “cursor”, o sea una tabla de memoria, donde se encuentra la respuesta enviada por el Servidor (por ejemplo, los nombres de todos los vendedores que hoy vendieron por un monto superior a 500 dólares)
- Ni la aplicación (el sistema de contabilidad, de ventas, de tesorería, de cobranzas, etc.) ni el Cliente jamás tocan a los datos, solamente el Servidor puede hacer eso.
- El Servidor sólo toca a los datos si recibe un pedido del Cliente para hacerlo. Si el Cliente no se lo pide, el Servidor jamás toca a los datos.
Ventajas de usar Cliente/Servidor
Control centralizado: Para poder acceder a una Base de Datos se necesita el nombre de un usuario y su contraseña y los permisos (también llamados derechos o privilegios) correspondientes. Una tabla .DBF puede abrirla cualquiera que conozca aunque sea un poquito de Visual FoxPro. Una tabla SQL no. Solamente podrá abrirla si tiene autorización para hacerlo.
Ocultamiento: Para abrir una tabla .DBF se requiere conocer en cual computadora se encuentra, en cual carpeta de esa computadora, y cual es el nombre de esa tabla .DBF. En buenos motores como Firebird SQL, no es necesario tener toda esa información. Podrías pedir conectarte a MISERVIDOR/MIBASEDATOSCOLEGIO y si previamente el Administrador de la Base de Datos definió a cual computadora se la conoce como MISERVIDOR y a cual Base de Datos de esa computadora se la conoce como MIBASEDATOSCOLEGIO, podrías realizar la conexión sin tener la menor idea del nombre real de la Base de Datos (podría ser DARWIN.FDB, por ejemplo) ni cual es la computadora (podría ser una computadora local, la que tiene el IP 192.168.0.25, por ejemplo; o podría ser una computadora remota, la que tiene el IP 181.120.90.145, por ejemplo).
Seguridad: Como consecuencia directa de los dos puntos anteriores, la seguridad que se puede obtener es muy grande. Si por ejemplo a un usuario solamente se le otorgó el derecho de hacer SELECT a la tabla ALUMNOS, él no podrá causarle un daño a la Base de Datos aunque lo intente y lo reintente. Primero, porque con un SELECT jamás podría causar daño, y segundo porque como ya vimos quizás ni siquiera sabe en cual computadora se encuentra la Base de Datos, ni en cual carpeta, ni cual es el nombre real de esa Base de Datos.
Velocidad: Los Servidores SQL están optimizados para conseguir una muy buena velocidad de respuesta. ¿Visual FoxPro te parece rápido? Si crees eso entonces es seguro que no has probado un buen motor SQL, tal como Firebird. El autor de este blog aún recuerda cuando un proceso que con tablas .DBF se demoraba más de 20 minutos en realizar, con Firebird finalizaba en 5 ó 6 segundos, es otro mundo.
Escalabilidad: Al mejorar el hardware de la computadora donde se encuentra el Servidor se puede conseguir un gran incremento en la velocidad de las respuestas.
Menos fallas: En las tablas .DBF un problema eterno es que pueden corromperse. Un corte de la energía eléctrica o de la conexión con el Servidor pueden dañar a las tablas de datos o a los archivos de índice. En un buen motor SQL (ya lo sabes: como Firebird) tal cosa no puede ocurrir. Aunque se corte la energía eléctrica 100 veces en un día, ninguna tabla de la Base de Datos será dañada.
Backups en cualquier momento: las tablas .DBF no se pueden copiar mientras están siendo usadas, primero debes cerrarlas y luego copiarlas. Con un buen motor SQL (y sí…Firebird) puedes realizar los backups cuando se te ocurra, ningún problema.
Mejor desarrollo de aplicaciones: como ya no debes escribir tanto código y además no debes perder tanto tiempo pensando en los algoritmos correctos, y haciendo un larguísimo proceso de prueba/error entonces puedes concentrarte en lo realmente importante: que tu aplicación se vea mejor, sea más fácil de usar, sea más completa. Esto te posibilitará aumentar las ventas y por lo tanto, ganar más dinero.
Conclusión:
Cambiar de la forma tradicional de programar a Cliente/Servidor no es algo que se puede conseguir de la noche a la mañana pero las ventajas de realizar ese cambio son muy grandes y deberían muy seriamente ser analizadas.
Porque en resumidas cuentas lo que se conseguirá será trabajar menos y obtener mejores resultados.
Artículos relacionados:
De DBF a SQL (1). Introducción
De DBF a SQL (2). Reemplazando comandos
De DBF a SQL (3). Entendiendo a los cursores
De DBF a SQL (4). Ejemplos de usar SELECT con una sola tabla
De DBF a SQL (5). Las funciones agrupadas
De DBF a SQL (6). Agrupando filas
De DBF a SQL (7). Poniéndoles condiciones a los grupos
De DBF a SQL (8). Ordenando las filas
De DBF a SQL (9). Uniendo tablas
De DBF a SQL (10). Obteniendo las primeras filas de una tabla
De DBF a SQL (11). Relacionando una tabla con otra tabla
De DBF a SQL (12). Relacionando una tabla consigo misma
De DBF a SQL (13). Relacionando a varias tablas entre sí
De DBF a SQL (14). Más sobre el uso de DISTINCT
De DBF a SQL (15). Usando subconsultas
De DBF a SQL (16). Más sobre las subconsultas
De DBF a SQL (17). Ejemplos de subconsultas
De DBF a SQL (19). Hallando los porcentajes sobre un total
De DBF a SQL (20). Los operadores especiales de comparación
De DBF a SQL (21). La técnica de los dos cursores
De DBF a SQL (22). Optimizando el uso del operador de comparación especial IN
De DBF a SQL (23). Usando la función CAST()
De DBF a SQL (24). Buscando texto
De DBF a SQL (25). Creando tablas y cursores
De DBF a SQL (26). INSERT, UPDATE, y DELETE, con subconsultas
De DBF a SQL (28). Conectándose a un Servidor
De DBF a SQL (29). Las cadenas de conexión ODBC a los motores SQL más populares
De DBF a SQL (30). Conectándose mediante ADO a las bases de datos
De DBF a SQL (31). Optimizando la escritura de los SELECT
De DBF a SQL (32). Mejorando la estética de los SELECT
De DBF a SQL (33). Usando la función SQLEXEC()
De DBF a SQL (34). Enviándole parámetros a la función SQLEXEC()
El índice del blog VFPavanzado
Visual FoxPro. Técnicas avanzadas 