Hace bastante tiempo, escuché acerca de las bases de datos de Object. Concepto fresco 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?¿Las bases de datos orientadas a objetos aún están en uso?
Las bases de datos OO nunca salieron de un nicho de mercado. Son buenos para algunas aplicaciones, donde la estructura de datos se presta a ser representada por un gráfico de objetos, pero nunca tuvieron 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 lenguaje de host: no hay desajuste de impedancia de objeto/relacional.
Sin embargo, todavía hay varios proveedores de OODBMS como Gemstone, Versant o Cardinal que están 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 variousothers han señalado, la piedra preciosa es conseguir un poco de atención debido a su apoyo a Seaside y Maglev (un puerto de Ruby a la piedra preciosa de la máquina virtual con Rails se ejecutan en él). Podemos encontrar que esto le da un poco de aprecio a la buena gente de Gemstone y con un poco más de atención al paradigma OODBMS.
Al menos desde mi punto de vista, están prácticamente muertos. Pero nuevamente estoy trabajando principalmente en software comercial. Tal vez en áreas académicas todavía están en uso en alguna parte.
Usamos Versant Object Database en el producto en el que trabajo. (Anteriormente FastObjects, anteriormente base de datos Poet). Es una base de datos de objetos y encontramos que funciona mucho mejor que un modelo relacional para algunos aspectos de nuestro producto, principalmente almacenando objetos de configuración, interconectados con el código de Java.
Ver también esta pregunta hecha anteriormente: https://stackoverflow.com/questions/52144/object-oriented-database-experiences
Necesito una ayuda sobre objetos rápidos. A menudo me quedo sin memoria virtual cuando analizo un XML de alrededor de 15 GB. Estoy usando un analizador de expatriados. ¿Tienes una experiencia similar? –
No realizamos ningún análisis de XML, utilizamos la utilidad 'ptxml' de Versant para exportar/importar bases de datos FastObjects en formato XML, pero eso es todo. – Jay
Salida db4o.
De hecho, los sistemas de bases de datos son una de las áreas en las que los cambios fundamentales son realmente difíciles. Miles de millones de dólares se gastan en sistemas de bases de datos relacionales y funcionan bastante bien. Son tecnología comprobada 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 algo 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 varios productos. Básicamente, predigo que las bases de datos relacionales estarán más orientadas a objetos en el futuro para manejar mejor los requisitos.
Empecé a usar Gemstone recientemente. GLASS (Gemstone en Linux (u OS-X) con Seaside (framework web smalltalk)) es probablemente el mejor entorno de desarrollo web para aplicaciones complejas. Smalltalk está haciendo un avivamiento, siendo "el rubí real".
El soporte para cambios de esquema y consultas es muy superior al de RDBMS.
Una diferencia importante es que esta vez son asequibles.
Usando 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 muchas cosas con muy pocos recursos. Lamentablemente, existen y han existido numerosos conceptos erróneos sobre 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 el futuro.
De hecho, los sistemas de bases de datos son una de las áreas que los cambios fundamentales son muy duro. Miles de millones de dólares son gastados 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 para nuestros problemas con las bases de datos (vi que el 30% de todas las filas de bases de datos contienen errores) es el uso de tipado y validación muy primitivos en SQL. Además, a pesar de que se denominan relacionales, son muy malos en el manejo de las relaciones. El resultado es 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 una gran cantidad de dinero en ellos, necesitan una gran cantidad de desarrolladores y mantenimiento haciendo trabajos rutinarios. 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.
Porque el costo de su software no es tan fácil de descubrir.
Comprobé Objectivity, db4o, versant, y ninguno de ellos tiene el precio del software por adelantado en su sitio web.
Ya casi perdí interés por eso.
¿Alguien sabe en algún lugar donde hay una comparación de precios y licencias de todos estos oodbs diferentes?
+1 para eso. "Llámenos para obtener una cotización" siempre significa "ridículamente caro", simplemente parece que no hay un OSS bueno, asequible o no viral, una base de datos de objetos madura. –
objetividad ha recorrido un largo camino desde este post, todavía es bastante caro, sin embargo –
La base de datos de objetos es un concepto genial hasta ahora. Sin embargo, las implementaciones están plaqueadas con 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 base de datos de objetos) y RDBMS realmente pueden vivir uno al lado del otro, de hecho, hay un gran lugar para un motor de datos en el nivel medio, aplicaciones/sistemas integrados, ... Además, una implementación correcta de un motor de datos permitirá el soporte para la persistencia de objetos en un bajo nivel y en niveles superiores, construcciones RDBMS/SQL. Esto significa que su aplicación puede elegir trabajar con Objetos, usar el motor de datos para 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. Conectamos las dos tecnologías y proporcionamos alternativas para que los desarrolladores programen en su interfaz preferida. Se puede argumentar que tenemos esto ahora, p. - SQL Server tiene soporte para alojar objetos CLR, PERO las implementaciones actuales sufren de desaceleración de la 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 BD, la solución debe convertirlos/traducirlos a datos de fila en una tabla.
PERO si revertimos la situación, es decir, - el motor de datos opera en Objetos, entonces no habrá impedancia de impedancia. Agregar proyecciones de datos bidimensionales no es más que la implementación de interfaz de una Objecct Collection, por lo que no hay realmente ninguna asignación/traducción que se produce cuando los objetos se exponen como filas de datos de una tabla. Esta es mi teoría
Así que tal vez la próxima ola de tecnología en esta área es un motor de datos que permitirá a los objetos como interfaz de bajo nivel y la interfaz RDBMS se sientan encima de ella. ¡Y esta tecnología está disponible ahora!
B-Tree Gold versión 4.0 Scalable Object Persistence 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 de elección para el próximo RDBMS, que básicamente es una capa sobre él. Dos de sus principales puntos clave son: Escalabilidad: 100 millones de insertos en 17 horas en una computadora portátil ordinaria/avg. Estabilidad: transacción de fuerza industrial que asegurará que la base de datos no esté dañada y pueda retrotraerse 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. B-Tree Gold versión 4.0 SOP ha cumplido con este requisito, por lo tanto, estamos realmente listos para implementar este tipo de solución, sin tener que meterla en el cuello, ya que SOP le da libertad de elección sobre cómo le gustaría usarla. Se puede usar de muchas maneras, p. - complementando los servidores RDBMS como estación de almacenamiento en caché de nivel medio, base de datos integrada en el lado del cliente, etc ... ¡sin mencionar el motor de datos de bajo nivel del servidor RDBMS mismo!
Consultar en un OODBMS como Gemstone es mucho más fuerte para consultas ad-hoc que SQL. –