28 de octubre de 2013

Ventajas y desventajas del uso de formularios basados en VCX o SCX

Autor: Drew Speedie
Traducido por: Ana María Bisbé York

Fragmento de la sesión VFP Tips and Tricks presentada por el autor en la Conferencia DevEssentials Kansas, 2004
Existen ventajas y desventajas para crear/guardar formularios VFP en .SCXs o .VCXs. He aquí algunas de ellas:

Formularios basados en VCX: VENTAJAS
  • Fácilmente subclaseable
  • Muchos formularios pueden estar contenidos en un fichero VCX/.VCT (desventaja para desarrollo en grupos)
  • Posibilidad de utilizar propiedades y métodos protegidos (Protected) y ocultos (Hidden)
  • Puede sustituir una subclase DataEnvironment definida por el usuario (programa .PRG) en tiempo de ejecución.
  • Control completo sobre la apertura de tablas/vistas
Formularios basados en VCX: DESVENTAJAS
  • No puede utilizar DataEnvironment visual nativo
  • Como no puede utilizar DataEnvironment visual nativo, debe llenar manualmente las propiedades ControlSources y RecordSources
  • Más dificultad para ejecutar/probar, son necesarios 2 ó 3 comandos
  • No existe una vía directa para devolver un valor de un formulario modal
  • No tiene disponible el Asistente de formulario (de todas formas no recomendamos utilizar asistentes nativos...)
  • Si varios formularios están contenidos en una librería .VCX/.VCT, el desarrollo en equipo se hace más difícil, debido a que es más complicado que más de un desarrollador trabajen con formularios diferentes guardados en el mismo archivo .VCX
Formularios basados en SCX: VENTAJAS
  • Puede utilizar DataEnvironment visual nativo
  • Si se utiliza DataEnvironment, puede llenar ControlSources y RecordSources a través de los cuadros desplegables
  • Es fácil de ejecutar/probar, con un comando o con la opción Ejecutar en la barra de herramientas estándar.
  • Una vía simple, directa para devolver un valor de un formulario modal.
  • Puede sustituir una subclase DataEnvironment definida por el usuario (programa .PRG) en tiempo de ejecución.
  • Tiene disponible el Asistente de formulario (de todas formas no recomendamos utilizar asistentes nativos...)
  • El desarrollo en equipo es menos problemático porque cada formulario está siempre guardado en su propio archivo .SCX/.SCT
Formularios basados en SCX: DESVENTAJAS
  • Un poco más difíciles de subclasear; la intención es utilizarlo en el nivel instanciado.
  • Sólo un formulario por archivo .SCX/.SCT (muchos archivos individuales), pero puede ser una ventaja en el desarrollo de proyectos en equipo (vea arriba)
  • No se pueden utilizar propiedades y métodos protegidos (Protected) y ocultos (Hidden)
  • No existe control real sobre la apertura de tablas/vistas en el DataEnvironment (aunque, si lo desea, lo puede realizar en el Form.Load(); pero perderá los beneficios de utilizar un DataEnvironment nativo, mientras tiene otros ventajas de formularios basados en SCX)
Existe una vía de tomar lo mejor de ambos mundos, particularmente para tomar las ventajas de poder agregar cursores a un formulario basado en .SCX DataEnvironment, donde los nombres de tablas y nombres de campos están disponibles en varias interfaces del Diseñador de formularios:
  1. Crea un formulario basado en .SCX
  2. Agregue cursores al DataEnvironment – estos cursores nunca serán abiertos en tiempo de ejecución, así sean tablas/vistas cuando estás utilizando objetos de negocio o DataEnvironment de usuario.
  3. Establecer la propiedad DataEnvironment.AutoCloseTables a .F.
  4. Establecer la propiedad DataEnvironment.AutoOpenTables a .F.
  5. Establecer manualmente el entorno de datos:
    • Agregar código manual en el Form.Load()
    • Agregar código en el Form.Load() para el lazo entre el DataEnvironment (ignorado en tiempo de ejecución) y ejecutar el código equivalente al objeto Cursor y sus propiedades en los objetos Relation.
    • Implementar su objeto DataEnvironment sustituto/de usuario
    • Liberar el control de los datos a su objeto de negocio
Esta técnica permite aprovechar todas las ventajas de los formularios basados en .SCX, mientras acomoda todas las consideraciones que típicamente fueron creadas para formularios basados en .VCX. Incluso en un desarrollo n-capas, si su capa intermedia proporciona cursores a la capa de presentación, puede agregar los cursores al DataEnvironment donde están disponibles en tiempo de diseño, y establecer simplemente la propiedad Alias al alias proporcionado en la capa intermedia.

Espero que les haya resultado de utilidad.

Saludos,

Ana María Bisbé York

7 de octubre de 2013

Visual FoxPro y la optimización Rushmore

Articulo original: Visual FoxPro y la optimización Rushmore
Publicado en: UTMag/Rapozine http://www.UniversalThread.com/Magazine
Autor: Carlos Alejandro Pérez (Resistencia, Chaco, Argentina)

La optimización

Mucho se ha escrito de la optimización Rushmore, característica inconfundible de FoxPro. Muchos programadores, incluso sin conocer profundamente a FoxPro, intuyen que es algo que tiene que ver con los índices, algo que acelera las consultas.


Pues entonces ¿qué es precisamente la optimización Rushmore? Podríamos decir, por ahora, que es la utilización de los índices para acelerar la recuperación de datos. Dicho así, nos quedamos con gran cantidad de preguntas sin respuestas.


Para entender un poco cómo funciona esto, demos un poco de base teórica la que seguramente no nos vendrá mal. Quizás algunas partes sean un poco difíciles de entender, pero por lo menos los conceptos al final de cada punto serán igualmente útiles para el lector. Tampoco espere el lector que se toquen todos los aspectos de Rushmore, debido a que Microsoft - como haría cualquier otro fabricante - no da mayores detalles de su arquitectura interna.

Jerarquía de almacenamiento

La jerarquía de almacenamiento se refiere a las distintas capas que tiene una computadora para almacenar información. En base de datos, la jerarquía es:


  1. Memoria RAM física. Poca capacidad (menor que 2 GB), gran velocidad (10ns). Volátil.
  2. Medio magnético de acceso aleatorio. Normalmente es un disco rígido. Capacidad intermedia (unos 50 GB), velocidad media (7 ms). No volátil.
  3. Medio magnético de acceso secuencial. Normalmente es una unidad de cinta DLT, DAT, etc. Gran capacidad (centenares de gigabytes) velocidad lenta (del orden de segundos a minutos). No volátil.


Por lo tanto, decimos lo siguiente: las bases de datos operan en la jerarquía 1 y 2. En la 1 se efectúa el PROCESO, en la 2 el ALMACENAMIENTO. De esto se deduce fácilmente que para que exista el PROCESO, debe transferirse información desde la jerarquía 2 a la 1, y viceversa. Volveremos sobre estos conceptos más adelante.

Modelo relacional

Como los sistemas de información hasta comienzos de los 70s eran propietarios, y sus datos se almacenaban en formatos también propietarios, se consumían muchas horas-hombre en alterar la funcionalidad de un sistema, ya que no existía una separación clara entre el programa y los datos.


Se necesitaba lo que se conoce como "independencia de datos", es decir, el programa debía estar protegido de los cambios que pudiesen haber en los datos. Para ello era claro que además del programa se necesitaba algo que estuviese separado del mismo: una base de datos. La base de datos provee independencia física, porque no importa cómo esté almacenada la información, ni el tamaño de las páginas, ni sobre qué soporte , el programa sigue viendo de la misma forma a los datos. También provee cierta independencia lógica, ya que el hecho de agregar columnas o procedimientos almacenados no debe influir sobre el programa preexistente (esto no es cierto, obviamente, si quitamos columnas, etc.).


Hasta esa época, los procesos en COBOL actuaban sobre archivos parecidos a los de texto, pero algunos usaban delimitadores especiales entre campos, otros utilizaban mecanismos de direccionamiento para saber dónde comenzaba y finalizaba cada campo, etc. Cada uno de estos mecanismos tenía limitaciones.


Ahora bien ¿qué es un modelo? Es un conjunto de conceptos utilizados para describir datos. ¿Y por qué relacional? Porque está basado en la teoría de conjuntos, donde el término "relación" se aplica a una asociación entre dos o más elementos de un conjunto. O sea una tabla.


El modelo relacional está basado en "tablas", las cuales son "relaciones". Esto debe quedar bien claro: las tablas son las relaciones. Cada tabla está compuesta de filas y columnas. Repitamos mentalmente: las tablas son relaciones. "Tabla" y "relación" son sinónimos.


La famosa "relationship" entre dos o más tablas NO es la relación que da el nombre al modelo relacional. Para eso, se utilizará el término vínculo, porque en español la traducción de "relation" y "relationship" conduce desafortunadamente a la misma palabra "relación". Por ello, la comunidad de habla hispana adoptó otros términos para referirse a "relationship", el más aceptado es "vínculo". Recordemos, pues, que el "modelo relacional" se llama así porque las tablas son relaciones.


El modelo exige que cada tabla debe necesariamente tener una clave. ¿Qué es una clave? Es el conjunto mínimo de columnas de la tabla que definen unívocamente la existencia de una fila. Por ejemplo, en una tabla PADRON la clave sería DNI, en una tabla ARTICULOS la clave sería (codigo_rubro,codigo_articulo), y así sucesivamente. Nótese que debe el conjunto "mínimo". En nuestra tabla PADRON, las columnas DNI y NOMBRE también definirían unívocamente la existencia de una fila, pero no sería un conjunto mínimo. Por esto se dice que DNI y NOMBRE no son una clave, sino una "superclave". En modelo relacional, las superclaves deben ser evitadas.


Las claves primarias, las candidatas, todas son claves. De esto se desprende que no pueden existir en el modelo relacional claves que sean repetidas, porque la definición prohibe esto. La clave primaria sería nuestro índice principal en VFP, la candidata nuestro índice candidato en VFP.


Esto deriva en una consecuencia insospechada: como dijimos recién, en el modelo relacional no es posible que los campos que conforman la clave se repitan. Si lo pensamos un poquito, esto da como corolario que que ninguna tabla puede tener dos filas idénticas.


Pero nosotros, viejos programadores de FoxPro, sabemos que esto no es así, que muchos de nuestros sistemas tienen filas duplicadas, y que muchas tablas tienen los campos clave duplicados. ¿Qué estará pasando? Lo vemos un poco más adelante.

El álgebra relacional

¿Por qué tanto alboroto con el modelo relacional? Porque era la primera vez que se describía una estructura de datos basándose en modelos matemáticos precisos. Como las tablas son "relaciones", las operaciones entre esas relaciones formó el llamado "álgebra relacional".


A ver si entendemos: así como existe una operación de suma para los números en el álgebra común, existe una operación de unión de tablas para el álgebra relacional. El álgebra común opera con números, el álgebra relacional opera con tablas. Así como el álgebra relacional devuelve resultados que son otros números, el álgebra relacional devuelve resultados que son otras tablas. Este es un concepto fundamental: los resultados del álgebra relacional son siempre tablas.

Entonces, hacia 1973 el modelo estaba completo. Se definieron cinco operaciones básicas para operar con las tablas, que formaron la base del álgebra relacional: selección, proyección, renombrado, reunión y unión. Cada operación actuaba sobre tablas, y devolvía necesariamente otras tablas.


Incluso para que el álgebra tuviese todas la operaciones, se derivó la operación de división entre dos tablas, un tanto exótica porque es la secuencia de varios operadores simples, y se la incluyó para que el modelo del álgebra fuese cerrado y completo (es decir, hubiera siempre una forma de recorrer el camino inverso en una cadena de operaciones, por lo tanto, para una multiplicación entre tablas - producto cartesiano - debería por lo tanto existir la división, etc.)


Si nos fijamos bien, no existe la operación de borrado. En efecto, la operación de borrado no se contempla en el álgebra relacional. Tampoco se contempla el "ordenado". ¿Y entonces?