Motores De Persistencia.

 
Dr. Vicent-Ramon Palasí Lallana.
Director Académico de la
Universidad Francisco Gavidia.

É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.

4. Bases De Datos Orientadas A Objetos.

Como hemos visto en el apartado anterior, la opción consistente en que toda la aplicación use un mismo modelo teórico relacional no es la más adecuada.

Examinemos ahora la opción en que toda la aplicación tenga un único modelo teórico, pero que éste sea el de orientación a objetos. Esta opción, que se refleja en la figura 8, implica que el formato de datos que usa toda la aplicación es el formato de objetos.


Figura 8. Arquitectura de una aplicación con base de datos orientada a objetos.

Para un programa resulta natural trabajar con objetos. Sin embargo, esto es imposible para las bases de datos tradicionales, basadas en el modelo relacional. Para resolver este problema han aparecido las bases de datos orientadas a objetos. Al contrario de sus homólogas relacionales, que trabajan con registros, las bases de datos orientadas a objetos guardan y recuperan objetos. Por lo tanto, la comunicación de este tipo de base de datos con un programa orientado a objetos es posible.

Aunque, sobre el papel, ésta es la mejor opción para implementar una aplicación de base de datos, en la práctica presenta una serie de problemas importantes, debido a las características actuales de las bases de datos orientadas a objetos. Éstas no están tan maduras como sus homólogas relacionales y, por lo tanto, no gozan de la abundancia de herramientas, la fiabilidad, facilidad de administración y rendimiento de estas últimas.

Lo que es peor, las bases de datos orientadas a objetos frecuentemente son incompatibles entre ellas. Esto hace imposible migrar una aplicación desde una base de datos orientada a objetos a otra, lo que nos obliga a depender de un único proveedor (fenómeno conocido como “vendor lock-in”), con todas las inconveniencias que esto supone (obligación de aceptar los aumentos de precio del proveedor, falta de soporte si el proveedor sale del mercado, etc.).

ATRAS         SUMARIO         SIGUIENTE