Hola invitado         31 Jul, 2010 - 07:53
Menú principal
 
Ads
 
Patrocinadores
 
Anuncios
 
© 2009 PortalFox

¿DBCs o tablas libres? Los pro y contra

(1331 palabras totales en este texto)
(17804 lecturas)  Versión imprimible

¿DBCs o tablas libres? Los pro y contra

Autor: Mike Lewis (www.ml-consult.co.uk)

Texto original:
-- DBCs or free tables? The pros and cons --
http://www.ml-consult.co.uk/foxst-32.htm

Traducido por: Ana María Bisbé York (amby@telefonica.net)
Para: PortalFox (www.portalfox.com)


Si no está seguro de si debe colocar sus tablas de Visual FoxPro en un contenedor de Bases de datos (DBC – Data Base Container) o dejarlas como tablas libres lea…

Una pregunta muy frecuente en nuestros Cursos de entrenamiento en VFP es si es mejor utilizar un contenedor de bases de datos (DBC) o dejar que las tablas permanezcan libres. Las tablas basadas en DBC tienen un grupo de ventajas; pero también pueden causarnos problemas por imprudencia o manejo incorrecto. Con este artículo vamos a sopesar los pro y los contra de cada proceder.

Primero, veamos algunos argumentos en favor del DBC

Campos con nombres largos

Para muchos desarrolladores es muy beneficioso. Los nombres de campos en tablas basadas en DBC pueden contener hasta 128 caracteres, comparados con los 10 que se admiten en tablas libres. Por tanto, puede nombrar sus campos con algo así como Total_Ventas_Periodo_Anterior en lugar de una abreviatura tipo TotVenPerA. Sin embargo, los nombres todavía se limitan a letras, dígitos y guiones bajos (o subrayados) y no hay control sobre las teclas mayúsculas.

Observe que los nombres de las etiquetas de índices están todavía sujetos a diez caracteres. Si el nombre de su campo es Empleado_Id, entonces, si lo marca como índice el nombre de la etiqueta de índice será Empleado_i.

Encabezados y comentarios

Puede asignar un encabezado que sea amigable para el usuario para cualquier campo. Los encabezados pueden contener hasta 254 caracteres, incluyendo puntuación, espacios y mezcla de letras mayúsculas y minúsculas. Los encabezados se muestran como encabezados de columnas en los controles Grids y ventanas Examinar, y además como encabezado predeterminado al arrastrar campos desde el Entorno de datos en los diseñadores de Informes y Formularios.

Además, puede comentar cada campo. Esto será muy útil para grabar una pequeña descripción del campo, de igual forma que escribe comentarios en su código. Los comentarios se muestran al final de la ventana del Administrador de proyectos al colocarse en el campo. Los comentarios son de gran beneficio para los desarrolladores. Normalmente los usuarios no los ven.

Reglas de negocios

El DBC puede contener reglas de validación, reglas de formato, máscaras de entrada, valores predeterminados y desencadenantes. Estas son ventajas obvias, ya que permiten guardar estos elementos de forma centralizada sin necesidad de escribir código para implementarlas individualmente. Por ejemplo, al guardar las reglas de validación para un campo en particular, esta regla será universalmente obligada para toda la aplicación, sin ninguna acción particular, por parte del programador. Además si la regla cambia, será necesario implementar el cambio en un solo lugar.

Sin embargo, no todos los programadores gustan de la idea de almacenar las reglas de negocio en el DBC – especialmente las reglas de validación y desencadenantes. Una razón para esto es que tiene menos control sobre su cronometraje. En un formulario de entrada de datos basado en tablas con buffer no se dispara la regla de validación hasta justo antes que el registro sea admitido, es decir, cuando el usuario hace clic en el botón Salvar. Puede preferir validar el dato cuando el usuario mueve el foco fuera del campo, de tal forma que el usuario pueda corregir el error inmediatamente. Además, para poder confiar en las reglas de validación y desencadenantes del DBC, debe escribir el código de tratamiento de errores.

Transacciones

Ese es otro argumento fuete a favor del DBC. En resumen, una transacción es una serie de actualizaciones que pueden ser realizadas en su totalidad o ninguna de ellas. El ejemplo clásico es la transferencia de fondos de una cuenta corriente a una cuenta depósito. Si la aplicación falla después que la cuenta corriente ha sido actualizada; pero antes de la actualización de la cuenta depósito, no estarán balanceadas las cuentas y el dinero se habrá “perdido”. Será preferible anular la actualización, para que el balance original se mantenga. El proceso de transacción le permite hacerlo así.

Las tablas que están almacenadas en DBC pueden tomar parte en transacciones, las tablas libres no pueden. (Observe que el proceso de transacción no es el mismo que de Buffering, que sí es posible con tablas libres y tablas enlazadas a DBC).

Relaciones persistentes

Un DBC puede almacenar detalles sobre las relaciones entre las tablas. Esto se muestra como líneas dibujadas entre los campos relacionados (o, más precisamente, entre las expresiones de índice relacionados) dentro del diseñador de Bases de Datos. A diferencia de las relaciones que crea en su código (por ejemplo, con SET RELATION), estas relaciones persisten incluso cuando la aplicación no está corriendo – de aquí proviene su nombre.

Las relaciones persistentes no tienen efecto en su código. Si escribe un código para mover el puntero de registro en la tabla padre, tendrá que tomar medidas para asegurar que el puntero de registro se mueva al registro apropiado de la tabla hija. La ventaja de las relaciones persistentes es que proporcionan el predeterminado para las relaciones creadas en el diseñador de consultas, el entorno de datos y varios asistentes. También cumple un rol en la documentación de la Base de Datos – las líneas conectadas en el diseñador de base de datos le ofrece un rápido resumen visual de cómo están relacionadas las tablas.

Ventajas de las tablas libres

Con todas las ventajas que hemos comentado antes, se podrá sorprender de que alguien quiera continuar con tablas libres. De hecho las tablas libres tienen un grupo de ventajas por si mismas.

Sencillez

Las tablas libres son esencialmente más sencillas que los DBCs, y pueden provocar menos conflictos cuando está generando la aplicación.

Con las tablas basadas en DBC, tendrá un grupo de problemas para asegurar que el DBC mantenga sincronizados las tablas e índices. Tanto el DBC como las DBF contienen un registro de la estructura de la tabla, y ocurrirá un error si estos no coinciden. Ocurre de forma similar para las etiquetas de índice. Esto significa que, cuando haga cualquier cambio estructural de un archivo de datos los que han sido desplegados en el sitio del usuario, debe ser cuidadoso de desplegar una copia actualizada del contenedor de base de datos también.

Otro problema surge si mueve la Base de datos o las tablas a otro directorio. El DBC contiene un apuntador a los DBFs y cada DBF contiene un apuntador de retorno a su DBC padre. Si la localización relativa de estos archivos cambia, los punteros serán incorrectos y el usuario verá inesperados mensajes en cualquier momento que cualquier fichero intenta abrirse. (Esto sólo afecta las rutas relativas entre los ficheros, si mantiene su DBC y DBFs en el mismo directorio, este problema no va a ocurrir.)

Las tablas libres estás libres de estos problemas. Desde muchos puntos, desarrollar tablas libres es considerado más sencillo que desarrollar con tablas integradas a DBC.

Compatibilidad

Si desea compartir tablas entre Visual FoxPro y otras herramientas de desarrollo o aplicaciones (incluyendo FoxBase, FoxPro para DOS y FoxPro para Windows), estará obligado a emplear tablas libres. En general, las tablas integradas a DBC no son compatibles con productos anteriores. De hecho, incluso las tablas libres son incompatibles si fueron creadas en VFP (a menos que hayan sido creadas con el comando COPY … TYPE FOX 2X ). Sin embargo, las tablas creadas en otros productos pueden ser utilizadas dentro de VFP – siempre que no modifique su estructura dentro de VFP o las coloque dentro del DBC.

¿La respuesta?

Entonces, ¿qué tipo de tabla debe utilizar? Nosotros preferimos los DBC – excepto donde haya temas de compatibilidad que fuercen a utilizar tablas libres. Pero las circunstancias y aplicaciones son diferentes y se debe aplicar en cada caso el criterio que corresponda. Esperamos con este artículo haber dado la información necesaria para ayudarle a crearse su propia opinión.

Mike Lewis Consultants Ltd. Noviembre 2003.



Todas las marcas y los logos utilizados en este sitio son propiedad de sus respectivos dueños.
Los artículos, noticias y comentarios son propiedad y responsabilidad de sus respectivos autores.
Copyright © 2000-2010 PortalFox. Todos los derechos reservados.