database - relaciones - herencia en base de datos orientada a objetos
¿Las bases de datos orientadas a objetos aún están en uso? (10)
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.
Hace bastante tiempo, escuché acerca de las bases de datos 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?
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.
Echa un vistazo a db4o .
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 y consultas de esquema 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 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.
En la vida real, eso simplemente no es verdad. 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.
Revisé Objectivity, db4o, versant, y ninguno de ellos tiene el precio del software en su sitio web.
Ya casi perdí interés solo por eso.
¿Alguien sabe en algún lugar donde hay una comparación de precios y licencias de todos estos oodbs diferentes?
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 la 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, ... También , 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, por ejemplo, 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 base de datos, la solución debe convertirlos a datos de fila en una tabla.
PERO si invertimos la situación, es decir, el motor de datos opera 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 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 sea un motor de datos que permitirá a los Objetos como una interfaz de bajo nivel y una interfaz RDBMS situarse encima. ¡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 garantizará 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, por ejemplo, como complemento de los servidores RDBMS como estación de 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!
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 funcionando 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 otros han notado, Gemstone está recibiendo un poco de atención debido a su soporte para Seaside y Maglev (un puerto de Ruby para Gemstone VM con Rails corriendo sobre é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.
Utilizamos la Base de datos de objetos Versant 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 previamente hecha: https://.com/questions/52144/object-oriented-database-experiences