| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos |
Artículo "Motores de persistencia"
Este artículo estudia el problema que supone el hecho de que los programas y las bases de datos tratan los datos de forma diferente. Se estudian diferentes soluciones a este problema y se concluye que la mejor es usar un motor de persistencia. Se informa sobre los principales motores de persistencia que existen en el mercado.
Artículo "Motores de persistencia" (continuación)
3. APLICACIONES TRADICIONALES. Como conclusión de lo que se ha dicho hasta ahora, una aplicación está formada por un programa y una base de datos que se comunican entre sí. El programa suele estar diseñado según el modelo orientado a objetos y, por lo tanto, trabaja con datos en formato de objetos. Por el contrario, la base de datos está diseñada según el modelo relacional y, por lo tanto, trabaja con datos en formato de registros. Esto introduce una dificultad importante, porque los dos formatos de datos (objetos y registros) son incompatibles entre sí. Así, cuando el programa quiere guardar o recuperar los datos en disco (para que no se pierdan entre ejecuciones), lo hace n forma de objetos, pues es el formato de datos que conoce. Sin embargo, la base de datos no puede guardar o recuperar objetos, pues está diseñada para guardar o recuperar registros (y no objetos), que es el formato de datos que ella reconoce. Esto se muestra en la figura 6. Resumiendo, los formatos de datos que utilizan el programa y la base de datos son incompatibles entre sí. Podemos decir que el programa y la aplicación hablan “idiomas diferentes” y, por lo tanto, debemos encontrar una solución para que se comuniquen. Figura 6. El programa y la base de datos usan diferentes formatos de datos La solución más obvia a este problema es hacer que uno de los componentes hable el idioma del otro. Es decir, que un componente use el formato de datos del otro. Así, la primera opción que examinamos en este artículo es la de que el programa esté diseñado para tratar con datos relacionales, la cual se refleja en la figura 7. En esta opción, tanto el programa como la base de datos hablan un mismo idioma: el relacional y utilizan como formato de datos el de registro. Por lo tanto, la comunicación es posible. Figura 7. Arquitectura de una aplicación tradicional Ésta era la forma de programar universalmente adoptada antes de la aparición de la orientación a objetos y sigue siendo la arquitectura dominante en El Salvador. Aún entre las empresas que utilizan lenguajes orientados a objetos, la mayoría programa sin tener en cuenta la orientación a objetos a la hora de usar los datos, los cuales se gestionan de forma relacional. El problema de esta arquitectura es que se desaprovechan las grandes ventajas de flexibilidad, facilidad de mantenimiento y facilidad de gestión de sistemas complejos que da la programación orientada a objetos. Asimismo, el código que opera con datos relacionales suele ser complejo, difícil de mantener y de ampliar y muy dependiente de la estructura de los datos.
Ir a la página: 1 2 3 4 5 6 7 Siguiente >>
Versión para imprimir
| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos| |