Pregunta

Esa es la pregunta. Indique solo una razón por la que piensa por qué falló OODB o por qué muchos sistemas hoy en día siguen utilizando bases de datos relacionales.

¿Fue útil?

Solución

¿Podemos responder más de una vez? Otra razón es que los DB relacionales tienen una base sólida en matemáticas: desde la definición de una relación, hasta las formas normales, la teoría es sólida como una roca. Es cierto que el modelo relacional no se asigna bien a OO, pero en mi humilde opinión, los beneficios y la estabilidad de ese modelo superan el problema de mapeo.

Otros consejos

La razón principal es SQL. Es muy útil poder utilizar los datos de una base de datos en otros contextos fuera de la aplicación y, a menudo, en las bases de datos de objetos, los datos se almacenan en un formato que no se puede consultar fácilmente. Con una base de datos relacional, los datos pueden convertirse en parte de un almacén de datos, por ejemplo, o simplemente consultados por administradores de sistemas, etc.

Creo que se debe a que " bases de datos de objetos " están resolviendo un problema que (casi) nadie realmente tiene. Para una simple persistencia de los gráficos de objetos, la serialización integrada en la mayoría de los entornos OO es "suficientemente buena". Si desea realizar operaciones sofisticadas en un subconjunto de sus datos, una base de datos relacional y SQL encajan perfectamente.

Aparte de algunas aplicaciones marginales (enormes gráficos de objetos que no se pueden guardar en la memoria, pero cuyas relaciones no se simplifican bien para el uso de RDBMS), realmente no hay necesidad de estas herramientas.

Solo porque OODB no es la corriente principal, todavía debemos considerar los éxitos que han tenido. Cache y Zope son ampliamente utilizados (relativamente), pero algunos estándares los considerarían exitosos.

Quizás la principal razón por la que OODB no se ha afianzado dramáticamente es el éxito de los sistemas híbridos relacionales de objetos que toman la mayor parte de la cuota de mercado potencial de OODB: PostgreSQL e Informix.

Sé que esto no responde directamente a la pregunta, pero es, creo, parte de la ecuación. Sin embargo, en general, creo que el impulso y los procesos de pensamiento muy arraigados que soportan las bases de datos de relaciones hacen que sea difícil para las personas cambiar. Actualmente, la profesión de DB está formada casi exclusivamente en teoría relacional, lo que hace que sus profesionales de DB estén muy interesados ??en evitar OODB y la academia enseña teoría de DB para practicantes casi exclusivamente en relación.

Hasta que sean grandes, los administradores de bases de datos (DBA) corporativos, los profesores y el currículo general y el desarrollo de personal más allá de los desarrolladores preparados para administrar OODB, creo que es poco probable que se vea atractivo para las masas, sin importar lo bueno que sea desde el punto de vista del desarrollo.

Bueno, es extraño ¿no? Existe un impulso tal hacia el diseño basado en dominios como el cenit del análisis y diseño orientados a objetos, y existen patrones empresariales que aprovechan los sistemas ORM para conservar nuestros objetos. Simplemente tiene sentido para mí que si su aplicación DISEÑO está orientada a objetos y centrada en el dominio, un OODB beneficiará enormemente su aplicación.

Aparte de las cuestiones relacionadas con la madurez y la aceptación, desde una perspectiva filosófica, una OODB parecería beneficiosa o una aplicación de OO. no tener que mantener esa capa de mapeo para empezar;)

Pero mira, si no estás haciendo un diseño de unidad de dominio y usas objetos como objetos de datos y como tus procedimientos almacenados, entonces realmente no lo vas a obtener;)

Los RDBM son (construidos sobre una base teórica sólida, han estado en el mercado durante mucho más tiempo, pueden modelar datos más fielmente que los OODB en muchos casos, pueden ser utilizados por más DBA que OODB). Esa es una razón en la forma de una tupla relacional.

Si puedo amplificar el punto de Phil: la estandarización de SQL. Los OODB han intentado lenguajes de consulta como OQL pero nunca parecieron seguir un verdadero estándar. También la calidad de los lenguajes de consulta era sospechosa, posiblemente debido a la falta de estandarización. Las normas fomentan la competencia, que genera calidad.

Una razón es que las bases de datos son sobre datos, y los objetos son sobre estructuras y algoritmos. Una vez que toma los datos y los integra en clases, caracteriza las relaciones y las operaciones en una estructura estática. Las bases de datos, por otro lado, tratan sobre la desestructuración de los datos en un conjunto de instancias de tablas atómicas que pueden reensamblarse en diferentes estructuras (generalmente con clases) sin perturbar la integridad de los átomos.

Las bases de datos son algo análogas a los hexahexaflexagons.

Eso y o / r-mappers. A través de ellos, la diferencia con los OO-DB verdaderos se hace mucho más pequeña, mientras que los beneficios mencionados siguen siendo válidos.

Las personas que tienen conocimientos técnicos no toman decisiones tecnológicas costosas. Las empresas que utilizan bases de datos relacionales emplean a muchas personas que se sienten amenazadas por los OODB y, por lo tanto, evitarán conocerlas.

Creo que hay dos razones filosóficas.

Primero, las personas tradicionalmente tienden a separar la persistencia de la funcionalidad real. Una vez que eliminas la "vida" de un objeto lejos de él y mantenerlo principalmente para la persistencia, se convierte en un registro, y luego hay una tendencia a tratarlo como un " sin vida " objeto de datos.

Siguiendo con eso, cuando las personas piensan en una gran colección de cosas muy similares, comienzan a pensar en ellas como tablas en lugar de objetos.

Creo que con O / R la distinción está comenzando a desaparecer. Por ejemplo, uso hibernate para volcar jerarquías de clases realmente complejas en una base de datos MySQL. Sin embargo, no escribo material de rendimiento crítico para mi proyecto, así que estoy seguro de que no se realiza de manera eficiente.

El motivo de la lenta adopción de OODB se basa en gran medida en algunos factores clave que hacen que las bases de datos SQL relacionales sean más populares y / o más apropiadas. Si bien las bases de datos orientadas a objetos puros se encuentran ahora en un estado en el que superan muchos de los inconvenientes del modelo relacional, faltan algunas piezas clave.

Por un lado, tienden a carecer de soporte para la administración central de la base de datos, aunque esto se está rectificando rápidamente en varios productos.

Una segunda razón es que muy pocos sistemas implementan un lenguaje de consulta estándar y en su lugar se basa en el lenguaje de programación o en lenguajes de consulta especializados para recuperar y manipular los datos almacenados. Este es un show stopper para muchos si tienen que aprender un nuevo lenguaje de consulta además de la mentalidad totalmente diferente de un programador utilizado para soluciones basadas en NoSQL. Además de eso, la mayoría de las bases de datos basadas en SQL / relacionales ahora tienen algo de soporte para el diseño orientado a objetos, además tenemos envoltorios como ORM que muchos usan para " omitir " los problemas de las bases de datos relacionales que no están disponibles en el lenguaje de programación elegido.

Pero estos problemas existen principalmente en entornos corporativos. Como bases de datos integradas en dispositivos pequeños, como almacenamiento de sitios web y en campos como el aeroespacial, se han vuelto muy populares y, en muchos casos, han reemplazado totalmente la necesidad de bases de datos relacionales regulares.

¿Quién sabe lo que depara el futuro?

La serialización proporcionada por la mayor parte del lenguaje le permite allanar los atributos del objeto y, por lo tanto, almacenarlos fácilmente en el RDBMS y recuperar objetos de manera similar no es un gran problema. La base ancha y sólida aún carece, lo que dificulta el uso de OODBMS a implementar.

Actualmente estoy pensando en hacer esto como mi proyecto de tesis de maestría para proporcionar un marco general para OODBMS que admita casi todos los componentes que se usan comúnmente en RDBMS de hoy en día, proporcionando así un DBMS estructurado no lineal. Mientras estudiaba, me topé con un proyecto llamado db4o que es un enfoque (implementado) de usar OODBMS solo para Java y .net, por lo que esta podría ser otra razón de falta de generalidad para todos los tipos de plataformas e idiomas.

Creo que es porque los grandes como Oracle habían estado invirtiendo en bases de datos relacionales mientras el movimiento orientado a objetos estaba ganando impulso ... puede que se conviertan en una corriente principal si Oracle / Microsoft invierten en él a lo grande ... lo que parece poco probable porque no tienen una razón sólida para hacerlo ... simplificará la vida de muchos programadores ... pero "simplificando la vida de los programadores" ¡No es un muy buen objetivo de negocios para ellos!

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top