¿Por qué las bases de datos de relaciones son más comunes que las bases de datos orientadas a objetos?¿Por qué los OODBMS no están tan extendidos como RDBMS?
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?
Una razón por la que RDBMS ha conservado su popularidad es porque 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 los RDBMS son sin embargo la mejor solución de propósito general para la gran mayoría de las tareas de administración de datos.
creo que es un caso de
Si no está roto, no lo cambie.
Las bases de datos relacionales están muy arraigadas.
En una palabra Interoperabilidad (gran palabra en un viernes por la noche <G>)
mayoría de las empresas tienen que trabajar con los 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 tiene 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.
Los datos suelen durar más tiempo y es más importante 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.
"Los datos suelen durar más tiempo y es más importante que el programa". - Amén. Los niveles intermedios van y vienen, pero la información vive para siempre. – duffymo
OODBMS no implica estar ligado a un lenguaje específico más de lo que RDBMS está obligado a procedimientos almacenados específicos de implementación. –
En teoría, tiene razón, pero en la práctica existen pocas implementaciones de RDBMS bien conocidas y que cuentan con el respaldo de herramientas, una vasta base de conocimientos y personas con experiencia. Mi empresa acaba de realizar una fusión corporativa e importamos datos de la base de datos de la otra compañía a nuestra base de datos (con muchas transformaciones, masa y limpieza de datos). Ambas compañías usaron Oracle y eso facilitó las cosas más que si la otra compañía utilizara una base de datos poco conocida. – softveda
Las bases de datos de objetos tienen un nicho muy agradable para problemas como la representación de la geometría, p. 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.
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ía 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 copia de seguridad 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 arruga, o lo toman en una dirección que no le es útil, o si le falta una característica clave que necesita, puede Simplemente descargue sus datos en un OODBMS competidor y transmita 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 a 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.
Proveedores OODBMS: para cambiar esto, necesita make it easy to leave you for your competitors. 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.
Para ejemplos trivales OODB y 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 los 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.
A continuación, pretende 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 forma que puedan recuperarse 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.
Por eso existe algo así como Hibernate: para poner una interfaz orientada a objetos en un sistema de almacenamiento RDBMS eficiente. Donde se ve otro tipo de almacenamiento realmente brillan son diferentes áreas problemáticas:
Los OODB no pueden funcionar mejor que los RDB porque no son fundamentalmente diferentes.
Los RDB llegaron para quedarse porque el hecho de que los RDB estuvieran diseñados para guardar gráficos de gran tamaño de forma eficiente en espacio y tiempo para guardarlos y recuperarlos, y también para tolerar errores y garantizar la integridad de los datos resolver en 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.
"Si no está roto no lo cambies" es tan estúpido ... ¿por qué hacer algo mejor o desarrollar software más rápido es algo malo? Mi última computadora no se rompió cuando la cambié, ¡estaba LENTO!Es mi objetivo como desarrollador buscar soluciones mejores y más eficientes. – billy