| 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)
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 incoveniencias que esto supone (obligación de aceptar los aumentos de precio del proveedor, falta de soporte si el proveedor sale del mercado, etc.). Como conclusión, aunque ésta pueda ser la opción preferible en un futuro, en el que las bases de datos orientadas a objetos alcancen una madurez y estandarización suficientes, en el presente resulta arriesgado aplicarla.
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| |