¿Siguen en uso las bases de datos orientadas a objetos?

Question

Hace bastante tiempo, escuché sobre bases de datos de objetos. Concepto genial y todo. Ahora, con el evento de ORM en todas partes, ¿alguien todavía usa alguno de los sistemas de bases de datos orientadas a objetos? ¿Son relevantes? ¿Son prácticos?

Answer 1

Las bases de datos OO nunca salieron de un nicho de mercado. Son buenos para algunas aplicaciones, donde la estructura de datos se presta para ser representada por un gráfico de objeto, pero nunca tuvo la ventaja convincente sobre un RDBMS para cruzar el abismo. La ventaja clave que se promociona para los productos OODBMS es la estrecha integración con el idioma del host: no hay desajuste de impedancia de objeto / relación.

Sin embargo, todavía hay varios proveedores de OODBMS como Gemstone , Versant o Cardenal que son haciendo bastante bien con sus productos. La tecnología es útil para algunos tipos de estructuras de datos y puede ser más eficiente que un RDBMS, pero tiende a ser débil para consultas ad-hoc en comparación con los dialectos SQL modernos.

Como varios others han notado que Gemstone está recibiendo un poco de atención debido a su apoyo a Seaside y Maglev (un puerto de Ruby a Gemstone VM con Rails ejecutándose en él). Podemos encontrar que esto le da a la gente amable de Gemstone un poco de presión y con un poco más de atención al paradigma OODBMS.

Answer 2

  

De hecho, los sistemas de bases de datos son uno de   las áreas que son los cambios fundamentales   realmente difícil. Miles de millones de dólares son   gastado en sistemas de bases de datos relacionales   y están funcionando bastante bien

En la vida real, eso simplemente no es cierto. Una razón importante de nuestros problemas con las bases de datos (vi que un 30% de todas las filas de la base de datos contienen errores) es el uso de tipeo y validación muy primitivos en SQL. Además, a pesar de que se denominan relacionales, son muy malos para manejar las relaciones. El resultado son modelos de datos desnormalizados y errores de actualización resultantes.

La razón por la cual a las empresas les gustan las bases de datos relacionales es porque son muy predecibles. Tienen que gastar mucho dinero en ellos, necesitan muchos desarrolladores y mantenimiento que realicen principalmente trabajos de rutina. No ven la cantidad de duplicación que podría eliminarse como una ventaja. El trabajo de rutina permite a los desarrolladores absorber los riesgos del trabajo difícil. Cambiar a un OODB mantendría el trabajo menos predecible.

Answer 3

Consulte db4o .

Answer 4

De hecho, los sistemas de bases de datos son una de las áreas donde los cambios fundamentales son realmente difíciles. Se gastan miles de millones de dólares en sistemas de bases de datos relacionales y funcionan bastante bien. Son tecnología probada y han sido lo suficientemente flexibles como para satisfacer la mayoría de las necesidades (utilizando ORM, por ejemplo, como usted dijo). Las bases de datos de objetos existen en realidad, incluso fuera de la academia. Pero no espere ver nada tan grande como SQL Server u Oracle en esa área en el corto plazo. Existen como una teoría y como pequeñas bases de datos específicas de aplicaciones y diversos productos. Básicamente, predigo que las bases de datos relacionales se orientarán más a objetos en el futuro para manejar mejor los requisitos.

Answer 5

Empecé a usar Gemstone recientemente. GLASS (Gemstone en Linux (u OS-X) con Seaside (marco web smalltalk)) es probablemente el mejor entorno de desarrollo web para aplicaciones complejas. Smalltalk está reviviendo, siendo & Quot; el verdadero rubí & Quot ;.

El soporte para cambios de esquema y consultas es muy superior al de RDBMS.

Una diferencia importante es que esta vez son asequibles.

Answer 6

Utilizamos Versant Object Database en el producto en el que trabajo. (Anteriormente FastObjects, anteriormente Base de datos del poeta). Es una base de datos de objetos y descubrimos que funciona mucho mejor que un modelo relacional para algunos aspectos de nuestro producto, principalmente almacenando objetos de configuración, interactuando con el código Java.

Vea también esta pregunta previamente hecha: https://stackoverflow.com/questions/52144/object- orientado a la base de datos de experiencias

Answer 7

Porque el costo de su software no es lo suficientemente fácil de averiguar.

Revisé Objectivity, db4o, versant, y ninguno de ellos tiene el precio del software por adelantado en su sitio web.

Ya casi he perdido interés solo por eso.

¿Alguien sabe en algún lugar donde hay una comparación de precios y licencias de todos estos diferentes oodbs?

Answer 8

Uso de GemStone para una aplicación comercial grande. Es genial y es muy práctico. Lo hemos usado durante varios años y durante ese tiempo nos ha permitido hacer mucho con muy pocos recursos. Lamentablemente, existen y han existido numerosos conceptos erróneos sobre las bases de datos de objetos y creo que esto los hace menos relevantes en el mundo de los negocios. Esperemos que algo como GLASS (GemStone, Linux y Seaside Smalltalk) cambie eso en el futuro.

Answer 9

Object Database es un concepto genial hasta ahora. Sin embargo, las implementaciones están plagadas de problemas de escalabilidad y estabilidad. Ahora con la encarnación correcta que se dirige a estas dos bestias, la ecuación puede cambiar.

Lo que pensé es que un motor de datos (no necesariamente una base de datos de objetos) y un RDBMS realmente pueden convivir, de hecho, hay un gran lugar para un motor de datos en las aplicaciones / sistemas integrados de nivel medio. .. Además, una implementación correcta de un motor de datos permitirá el soporte tanto para la persistencia de objetos a nivel bajo como a nivel superior, construcciones RDBMS / SQL. Esto significa que su aplicación puede elegir trabajar con Objetos, usar el motor de datos para la Persistencia de Objetos Y hacer que los Objetos estén disponibles como Filas / Columnas de una tabla a través de una interfaz RDBMS.

Esta es la configuración ideal. Unimos las dos tecnologías y ofrecemos alternativas para que los desarrolladores programen en su interfaz preferida. Uno puede argumentar que tenemos esto ahora, p. - SQL Server tiene soporte para alojar objetos CLR, PERO las implementaciones actuales sufren de desaceleración de impedancia. es decir, en la ruta de datos hay muchas conversiones / traducciones como objetos! = datos bidimensionales, por lo tanto, cuando su aplicación que trata con objetos los guarda en la base de datos, la solución tiene que convertirlos / traducirlos en datos de fila en una tabla.

PERO si revertimos la situación, es decir, si el motor de datos funciona en Objetos, entonces no habrá desajuste de impedancia. Agregar proyecciones de datos bidimensionales no es más que la implementación de interfaz de una Colección de Objetos, por lo tanto, en realidad no hay mapeo / traducción que ocurre cuando los Objetos se exponen como filas de datos de una tabla. Esta es mi teoría.

Entonces, quizás la próxima ola de tecnología en esta área sea un motor de datos que permita que los Objetos como interfaz de bajo nivel e interfaz RDBMS se asienten sobre ella. ¡Y esta tecnología está disponible ahora!

La persistencia de objetos escalables de B-Tree Gold versión 4.0 tiene esto como su principal objetivo de diseño. Alcanza las siguientes características y, por lo tanto, está bien adaptado para ser el motor de datos elegido para el próximo RDBMS, que básicamente es una capa por encima. Dos de sus principales puntos clave son: Escalabilidad: 100 millones de insertos en 17 horas en una computadora portátil ordinaria / promedio equipada. Estabilidad: transacción de fortaleza industrial que asegurará que DB no esté dañado y pueda revertir a un estado previamente comprometido.

Para que esto funcione, el motor de datos debe cumplir con la escalabilidad y la estabilidad requeridas por los servidores RDBMS. Una tarea muy difícil pero no imposible. El SOP de B-Tree Gold versión 4.0 ha cumplido este requisito, por lo tanto, estamos realmente listos para implementar este tipo de solución, sin realmente meterlo bajo nuestro cuello, ya que SOP le da libertad de elección sobre cómo le gustaría usarlo. Se puede usar de muchas maneras, p. - Complementando los Servidores RDBMS como estación de almacenamiento en caché de nivel medio, DB incrustado en el lado del cliente, etc. ¡sin mencionar ser el motor de datos de bajo nivel del servidor RDBMS mismo!

Answer 10

Al menos desde mi punto de vista, están prácticamente muertos. Pero, de nuevo, estoy trabajando principalmente en software comercial. Tal vez en áreas académicas todavía están en uso en algún lugar.