Mejorar el rendimiento mediante el acceso a datos basados en conjuntos
Uno de los factores más importantes a la hora de generar una aplicación cliente-servidor rápida y eficiente es reducir al mínimo la cantidad de datos que necesita extraer del servidor. Puesto que las aplicaciones cliente-servidor pueden tener acceso a cantidades de datos muy grandes en un servidor remoto, el uso de las técnicas tradicionales de desplazamiento local puede dar como resultado una aplicación cliente-servidor lenta. Para acelerar el rendimiento se utilizan técnicas de acceso a datos basadas en conjuntos para filtrar la cantidad de datos descargados.
Acceso eficaz a datos basados en conjuntos
Los datos remotos están basados en conjuntos; el acceso a datos remotos se realiza seleccionando un conjunto de datos de un gran almacén de datos mediante instrucciones SELECT - SQL. La diferencia más importante entre generar una aplicación local tradicional y una aplicación cliente-servidor es el contraste entre las técnicas tradicionales de desplazamiento en Visual FoxPro y las técnicas de acceso a datos del servidor basados en conjuntos.
Usar las técnicas tradicionales de desplazamiento
En la programación tradicional local, puede tener acceso a cantidades de datos discretas y, con frecuencia, de gran volumen, mediante el comando GOTO BOTTOM, para el cual puede, posteriormente, realizar una consulta. Puede desplazarse por los datos ejecutando un comando SET RELATION para crear una relación temporal entre dos tablas y, a continuación, ejecutando un comando SKIP para moverse por los registros relacionados.
Si bien este método de desplazamiento por los registros podría utilizarse para datos remotos, no sería eficiente para grandes almacenes de datos remotos. Por ejemplo, si crea una vista remota que tiene acceso a una tabla grande en un origen de datos remotos y a continuación ejecuta el comando GOTO BOTTOM tendrá que esperar mientras todos los datos de la vista se recuperan desde el origen de datos, se envían a través de la red y se cargan en el cursor de la vista del sistema local.
Usar consultas parametrizadas
Un enfoque más eficaz para el acceso a datos remotos es descargar únicamente los datos que necesita y entonces volver a consultarlos para obtener registros adicionales específicos o registros nuevos. Se utiliza una instrucción SELECT basada en parámetros para descargar un pequeño conjunto de datos específico y después tener acceso a nuevos registros mediante la función REQUERY( ) para solicitar un nuevo conjunto de datos.
No ejecute el comando GOTO BOTTOM sobre los datos del servidor remoto porque se originaría:
- Una carga innecesaria en los recursos de la red al descargar enormes cantidades de datos.
- Una disminución del rendimiento de la aplicación al tener que manejar datos innecesarios.
- Una posible reducción de la precisión de los datos del cursor local porque los cambios en los datos remotos no se reflejan en este cursor local hasta que no se ejecuta una nueva consulta.
Por ejemplo, si desea crear una aplicación cliente-servidor que tenga acceso a los pedidos de un cliente determinado, cree una vista remota que tenga acceso a la tabla Customer. Cree otra vista remota que tenga acceso a la tabla Orders, pero parametrice la vista basándose en el campo cust_id
. A continuación, emplee el registro del cliente actual como parámetro para la vista de la tabla Orders.
Puede utilizar el parámetro para establecer el alcance del conjunto de datos descargado a la cantidad justa de datos. Si solicita pocos datos, puede perder rendimiento porque necesitará volver a consultar el servidor remoto más frecuentemente. Si solicita demasiados datos, puede perder tiempo descargando datos que no va a utilizar.
Elegir el mejor diseño cliente-servidor
Los siguientes ejemplos describen la forma de aprovechar las ventajas de la tecnología cliente-servidor y evitar los inconvenientes de las técnicas de programación inadecuadas. El primer método utiliza técnicas de programación tradicionales para transferir todos los datos desde un origen de datos remoto hasta cursores locales, que se relacionan posteriormente con el comando SET RELATION. Los métodos segundo, tercero y cuarto adoptan progresivamente técnicas de recuperación de datos cada vez más inteligentes, que limitan de forma efectiva la cantidad de datos descargados con una metodología "puntual" que proporciona los datos más actuales y el tiempo de respuesta más rápido a través de una red.
Usar una estrategia cliente-servidor no optimizada
Una aplicación cliente-servidor sencilla y sin optimizar utiliza con los datos remotos las mismas técnicas de desplazamiento que usa para los datos locales. Por ejemplo, si tiene 10 millones de registros de clientes y 100 millones de registros de pedidos en un origen de datos remoto, puede crear una aplicación ineficaz que descargue todos los registros de las tablas Customer y Orders en los cursores locales. A continuación puede indizar basándose en 100 millones de registros de pedidos, crear una relación temporal entre las tablas Customer y Orders en los cursores locales, y utilizar el comando SKIP para desplazarse por los registros.
Este método no está optimizado para un gran rendimiento, pero podría ser útil si el extremo "uno" es local y el extremo "varios" es remoto.
Filtrar el extremo "varios"
Una aplicación cliente-servidor ligeramente mejorada limita el extremo "varios" de la relación, pero transfiere todo el extremo "uno" para que pueda pasar por los registros. En este ejemplo se crea una vista remota del extremo "varios" de la relación, la tabla Orders, parametrizada según el Id. de cliente. A continuación se descarga toda la tabla Customer.
Aunque crear una vista parametrizada sobre la tabla Orders es una mejora con respecto a descargar todos los pedidos, continúa transfiriendo información innecesaria al descargar toda la tabla Customer. Además, la tabla Customer está cada vez menos actualizada a medida que otros usuarios del sistema hacen cambios en ella. Este método puede ser adecuado si el extremo "uno" de la relación contiene un pequeño conjunto de datos.
Filtrar el extremo "uno"
Una técnica de programación cliente-servidor más apropiada crea vistas remotas para todos los datos remotos. El número de registros de Customer descargados a la vista remota de la tabla Customer se limita mediante la instrucción SELECT en esta vista para seleccionar solamente los clientes de una región. A continuación se crea una vista remota del extremo "varios" de la relación, la tabla Orders, parametrizada según el Id. de cliente.
Este método transfiere un conjunto de registros más reducido. El comando SKIP se usa para ir al extremo "uno" de la relación (la vista Customer). El comando REQUERY( ) se usa para tener acceso a nuevos datos en el extremo "varios" (Orders).
En este ejemplo se limita (se filtra) tanto el extremo "uno" como el extremo "varios" de la relación y también se puede utilizar el comando SKIP para desplazarse por los datos filtrados. Este método puede ser recomendable si el extremo "uno" de la relación, aun después de filtrarse, sigue siendo suficiente para proporcionar información para un conjunto de consultas sucesivas antes de volver a consultar el servidor remoto.
Usar la clave principal para tener acceso a la relación de uno a varios
El ejemplo de programación cliente-servidor más eficiente se olvida del lujo de utilizar el comando SKIP y crea un formulario que solicita la entrada o la selección del Id. de cliente, que se utiliza posteriormente como parámetro para una vista remota de la tabla Customer. Este parámetro se utiliza también para una vista remota de la tabla Orders.
Por ejemplo, podría crear un formulario de uno a varios en el cual la información del cliente constituyera el extremo "uno" y un control Grid mostrara el extremo "varios" de la relación. El control Grid puede estar enlazado al Id. de cliente elegido en el extremo "uno" del formulario. Entonces puede establecer la propiedad MaxRecords de CURSORSETPROP( ) a 1 y usar el código siguiente para llenar el lado "uno" del formulario:
SELECT * FROM customer WHERE customer.cust_id = ?cCust_id
Cuando el usuario desea ver el registro de otro cliente distinto, introduce o selecciona un nuevo Id. de cliente. El formulario vuelve a consultar en el origen de datos los pedidos del nuevo Id. de cliente y actualiza el control Grid con los nuevos datos de pedido.
Con estas técnicas, la aplicación descarga solamente los datos necesarios y en el momento en que se necesitan. La respuesta a través de la red se acelera si limita la cantidad de datos transferidos, y se proporciona al usuario información más actualizada si se vuelve a consultar el origen de datos justo antes de mostrar la información solicitada.
Este método se recomienda cuando se desea tener acceso a la relación de uno a varios de manera aleatoria mediante cualquier valor de clave principal. Quizás desee descargar las claves principales en un control, como una lista desplegable, al abrir el formulario, y después ofrecer un control que el usuario puede elegir para actualizar la lista de valores de clave principal cuando la requiera.
Usar el entorno de datos en aplicaciones cliente-servidor
Cuando utilice datos remotos en un formulario, debe incluir las vistas en el entorno de datos del formulario. Puede establecer la propiedad AutoOpenTables para el entorno de datos como False (.F.), de forma que pueda especificar el momento en que la aplicación actualiza las vistas con los datos remotos. Establezca la propiedad ControlSource para los cuadros de texto y otros controles enlazados a datos después de haber llamado al método OpenTables del entorno de datos, normalmente en el código asociado con el evento Init del formulario. Para obtener más información acerca de cómo establecer las propiedades de los formularios, consulte Crear formularios.
Vea también
Diseño cliente-servidor para un elevado rendimiento | Ubicar los datos en la plataforma óptima | Diseñar aplicaciones cliente-servidor | Seleccionar los métodos adecuados | Optimizar el rendimiento cliente-servidor | Implementar una aplicación cliente-servidor