engines - object database example
¿Por qué los OODBMS no están tan extendidos como RDBMS? (7)
Creo que es un caso de
Si no está roto, no lo cambies.
Las bases de datos relacionales están muy arraigadas.
¿Por qué las bases de datos de relaciones son más comunes que las bases de datos orientadas a objetos?
Si el paradigma de Programación Orientada a Objetos está tan extendido, ¿no deberíamos ver muchos OODBMS? ¿No funcionarían mejor que los RDBMS + OR / M?
El mayor problema que he visto es la falta de estandarización. En el mundo de RDBMS, puede llegar bastante lejos con cualquier base de datos aleatoria si conoce SQL. Básicamente todos lo implementan, con pequeñas variaciones. No conozco un solo RDBMS existente que no haga SQL: casi puede usar "RDBMS" y "SQL" indistintamente.
Lo más parecido a un OODBMS es quizás OQL, que ha sido un fracaso total.
Ninguna base de datos ha implementado gran parte de ella. Usé un OODBMS comercial bastante agradable hace un par de años, pero (a partir de 2007 o así, y estaba en la versión principal 8 o 9) ni siquiera admitía consultar un objeto por su nombre. El manual decía simplemente que esta parte de OQL aún no había llegado a su fin. (No estoy seguro, pero podrías haber sido capaz de hacer una llamada nativa para hacer eso).
La mayoría de las bases de datos de objetos que he visto recientemente tienen interfaces de idioma nativo en lugar de un lenguaje de consulta como OQL. El sistema que utilicé, por ejemplo, soportó (¡solo!) Perl y VB, IIRC. Limitar a su audiencia a solo un par de idiomas (u obligarlos a escribir wrappers, como nosotros lo hicimos) no es la manera de ganar amigos.
Debido a esto, no hay competencia y, por lo tanto, no es un plan de respaldo fácil. Si coloca sus datos en MS-SQL y Microsoft deja de apoyarlos, probablemente pueda volcar sus datos en Postgres y portar sus consultas, sin demasiados problemas. (Puede ser mucho trabajo, si tiene muchas consultas, pero no dudo que pueda hacerlo. Es un dolor, pero no es un reto técnico). O Oracle, o MySQL, o muchos otros, ambos comerciales. y gratis.
No existe tal cosa con un OODBMS: si el que está utilizando se agota, o lo toman en una dirección que no le es útil, o si le falta una función clave que necesita, no puede simplemente volcar sus datos en un OODBMS competidor y porte sus consultas. En cambio, estás hablando de cambiar una biblioteca principal y realizar cambios masivos en la arquitectura. Tan realista, estás limitado a un OODBMS comercial en quien realmente confías (¿puedes nombrar incluso uno?), O un OODBMS de código abierto en el que confías que tu equipo lo mantendrá cuando las cosas van mal.
Si esto suena como FUD, lo siento, no era mi intención. Pero he estado allí, y desde una perspectiva de administración de proyectos, dudaría en volver, a pesar de que el entorno de programación puede ser maravilloso. Otra forma de pensarlo es: mire cuán popular es la programación funcional en la actualidad, a pesar de la buena idea que es. Los OODBMS son así, pero lo que es peor, ya que no es solo su código, sino también su código y sus datos. Con mucho gusto comenzaría un gran proyecto en Erlang hoy, pero todavía dudaría en usar un OODBMS.
Vendedores de OODBMS: para cambiar esto, es necesario que sea fácil dejarlo por sus competidores . Podrías desenterrar OQL e implementarlo, o hacerlo en el nivel API como ODBC, o lo que sea. Incluso un formato de volcado estándar (usando JSON?) Y herramientas para importar / exportar a / desde eso para varios OODBMSs, sería un gran comienzo.
En una palabra Interoperabilidad (palabra grande en una noche de viernes <G>)
La mayoría de las empresas tienen que trabajar con sistemas heredados que se ejecutan en RDBMS. Si usaran OODBMS, aún necesitarían acceso a RDBMS para ciertas funciones. Es más fácil mantener una forma de acceder a los datos que dos.
Cuando tenga grandes nombres como Oracle y SQL Server en el mundo OODBMS y un rendimiento comprobado en una variedad de entornos, ENTONCES verá más proyectos usándolos.
Las bases de datos de objetos tienen un nicho muy agradable para problemas como la representación de geometría, por ejemplo, sistemas CAD, donde los gráficos de objetos pueden ser muy profundos. El rendimiento de JOIN se degrada rápidamente para alrededor de 7 tablas en la mayoría de los sistemas relacionales, por lo que las estructuras profundamente autorreferenciales en CAD se desempeñan mejor en las bases de datos de objetos.
Pero las aplicaciones importantes, como los datos financieros, se prestan a una representación relacional. El modelo relacional tiene una base matemática firme, y SQL es un lenguaje exitoso y popular. Hay pocos incentivos para que las instituciones financieras como los bancos, corredoras de bolsa y compañías de seguros se alejen de los SGBDR.
Los datos a menudo viven más tiempo y son más importantes que el programa. Entonces, incluso si comienzas un desarrollo totalmente nuevo hoy, debes considerar la imagen general. Hay más herramientas, procesos y personas con experiencia que trabajan con sistemas RDBM. Piense más allá del programa, ¿qué hay de la planificación de capacidad, minería de datos, informes, ETL, integración con otras fuentes de datos, etc. ¿Qué hay de su empresa adquirir otra empresa y así poner todos sus datos relacionales en su programa. RDBMS y las herramientas asociadas están tan arraigadas, comprobadas y poderosas que yo no tengo ningún sentido estratégico en el uso de cualquier otra cosa. En algún pequeño nicho tal vez, pero no en general.
Para ejemplos trival, los OODB y los RDB pueden ser muy diferentes. Especialmente si está trabajando con una cantidad de datos lo suficientemente pequeña como para poder leerla trivialmente en la memoria y escribirla de una vez. Pero, en última instancia, OODB necesita guardar los datos en un formato similar al de RDB: no son tan diferentes.
Considere un gráfico arbitrario de objetos que podrían usarse en una aplicación. Cada objeto puede ser referenciado por varios otros objetos. Cuando guarda un gráfico de objetos, no desea guardar objetos repetidamente cada vez que se hace referencia a ellos. Por un lado, si tuviera algún tipo de bucle o autorreferencia, su método de guardar el objeto entraría en un ciclo infinito. Pero en el caso general, es una pérdida de espacio. En cambio, cualquier data store importante necesita declarar un identificador único para cada objeto que se almacena (una clave, generalmente una clave sustituta en términos RDBMS). Cada otro objeto que lo hace referencia guarda el tipo de objeto y la clave, no guarda todo el objeto repetidamente. Así que aquí hemos recreado claves foráneas en nuestro almacén de objetos no RDB.
Luego, pretenda que queremos almacenar una lista de objetos (A1, A2, A3 ...) que están relacionados con otro objeto (B). Ya establecimos que almacenaremos claves en lugar de guardar los objetos ellas mismas dos veces. Pero, ¿almacena las claves de los objetos A1, A2, A3 ... en el objeto B, o almacena la clave para el objeto B en A? Si los almacena de la primera manera y tiene todas las A que desea, puede tomar rápidamente las B relevantes. La segunda forma en que lo contrario es verdad. Pero de cualquier manera es un trato unidireccional. Si desea consultar el reverso de lo que almacenó y sus objetos se almacenan como XML o JSON, es mucho análisis ineficiente a través de la información más irrelevante para encontrar la clave en cada archivo. ¿No sería mejor almacenarlos en un formato en el que cada campo estuviera separado, como columnas en una tabla?
En una relación de muchos a muchos, o en un caso en el que necesita encontrar una gran cantidad de objetos en ambas direcciones, esta estrategia se vuelve muy ineficiente. La única solución de rendimiento es hacer un objeto auxiliar para almacenar la relación, con un archivo para cada relación, de modo que el archivo consista en la clave de A y la clave de B para que puedan buscarse rápidamente. Recién hemos reinventado la tabla de referencias cruzadas.
Tablas con columnas, identificadores únicos (claves), tablas de referencias cruzadas ... Estas son las necesidades básicas para almacenar objetos de manera que se puedan recuperar de manera eficiente. Hmm ... ¿Eso suena como algo familiar? Una base de datos relacional proporciona exactamente esta funcionalidad. Además, varios proveedores han competido durante décadas para proporcionar el almacenamiento y la recuperación de datos más rápidos con las mejores herramientas para copias de seguridad, replicación, clustering, consultas, etc. Eso es mucho para que compita una nueva tecnología. Y, en definitiva, estoy diciendo que los RDBMS son básicamente una solución realmente buena para el problema del almacenamiento eficiente de objetos.
Esta es la razón por la cual algo como Hibernate existe: poner una interfaz orientada a objetos en un sistema de almacenamiento RDBMS eficiente. Donde ve que otros tipos de almacenamiento realmente brillan son áreas problemáticas diferentes:
- Para cualquier tipo de almacenamiento de documentos no estructurados (blogs, control de fuente o cualquier cosa que no se pueda asignar a filas y columnas), varias bases de datos NoSQL son ideales
- Mantener una historia de cambios fácil de consultar pero significativa (como diffs en el control de fuente) no es realmente bonita en los RDB. Algo como Datomic puede estar forjando un nuevo territorio aquí.
- Cada vez que el gráfico de objetos es simple o pequeño, la sobrecarga de una base de datos puede no ser necesaria.
Los OODB no pueden funcionar mejor que los RDB porque no son fundamentalmente diferentes.
Los RDB llegaron para quedarse porque salvar grandes gráficas de objetos de manera eficiente en espacio y tiempo para ahorrar y recuperar, y también tolerar fallas y tener alguna garantía de integridad de datos es el problema que los RDBs fueron diseñados para resolver en El primer lugar. Esta es la razón por la cual JPA e Hibernate también llegaron para quedarse, porque unen la brecha entre el objeto y los modelos de datos relacionales. Modelo de objeto para facilitar la manipulación en la memoria y relacional para la persistencia.
Una razón por la que RDBMS ha conservado su popularidad es que es una tecnología establecida, bien entendida y tiene un lenguaje estándar (SQL) compatible con varios proveedores. También tiene algunas buenas interfaces como ODBC y JDBC que hacen que se conecte con diferentes idiomas bastante bien. Una API estable es un factor importante para mantener una tecnología dominante.
Por el contrario, no hay un modelo claro para OODBMS, ni hay un lenguaje estándar, ni hay una API estándar. Ni siquiera hay un estándar de facto al tener una implementación de proveedor líder.
El concepto OODBMS podría funcionar mejor que RDBMS + ORM. Depende completamente de la implementación. Pero también es cierto que los OODBMS no resuelven el mismo conjunto de problemas que los RDBMS son buenos para resolver. Algunas tareas de administración de datos son mucho más fáciles si tiene integridad referencial y encabezados relacionales aplicados por la solución de administración de datos. Estas características están ausentes en el modelo OODBMS (al menos hasta ahora).
Hay mucho ruido en los blogs que las bases de datos relacionales son obsoletas, pero RDBMS es sin embargo la mejor solución de propósito general para la gran mayoría de las tareas de administración de datos.