Esa es la pregunta. Proporcione solo una razón por la que piense por qué OODB ha fallado o por qué muchos sistemas actualmente todavía usan bases de datos relacionales.¿Por qué las bases de datos orientadas a objetos no han tenido éxito (todavía)?
¿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 correlaciona bien con OO, pero en mi humilde opinión los beneficios y la estabilidad de ese modelo superan el problema de mapeo.
Sí puede. Y una buena segunda respuesta también. –
La teoría de conjunto/relacional es el rey, de hecho –
cualquier base de datos de OO podría proporcionar (y muchos lo hacen) acceso relacional a sus datos. –
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 con 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 formar parte de un almacén de datos, por ejemplo, o simplemente ser consultados por administradores de sistemas, etc.
Exactamente; SQL se puede utilizar desde casi cualquier entorno de programación (o incluso directamente desde el analizador de consultas), mientras que OOBBMS siempre tiene alguna forma no estándar y programática para consultar objetos en ellos. –
Puede consultar un DB4O con SQL. Hay un pequeño golpe de perf involucrado, pero es compatible. –
+1 solo para el mango. Pets.com? Pero creo que una de las principales razones es que cada OODB piensa que han resuelto todos los problemas del mundo, y cobran en consecuencia. Las empresas no quieren apostar el negocio en una empresa pequeña y no probada, razón por la cual Oracle existe. – chris
Si puedo ampliar el punto de Phil: la estandarización de SQL. Los OODB han probado lenguajes de consulta como OQL pero nunca parecían seguir un estándar verdadero. También la calidad de los lenguajes de consulta era sospechosa, posiblemente debido a la falta de estandarización. Los estándares fomentan la competencia, que genera calidad.
En mi proyecto de mascota actual usando db4o tengo una línea (C# 3.5): IList
¿Cuántas herramientas de terceros admiten esa línea? ¿Puede un administrador del sistema usar esa línea a las 11 de la noche? Para mí, la estandarización permite la creación de herramientas tanto para los desarrolladores como para el personal de administración del sistema. –
db4o admite varias formas de lenguajes de consulta. Como programador, estoy muy a favor de la variante de Linq fuera de curso. –
Eso, y o/r-mappers. A través de ellos, la diferencia con los OO-DB verdaderos se vuelve mucho más pequeña, mientras que los beneficios antes mencionados se mantienen válidos.
El hecho de que OODB no sea la corriente principal todavía debería considerar los éxitos que han tenido. Tanto Cache como Zope son ampliamente utilizados (relativamente), pero algunos estándares los considerarían exitosos.
Quizás la razón más importante por la que OODB no se ha asentado de manera espectacular es por el éxito de los sistemas relacionales de objetos híbridos 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 creo que es parte de la ecuación. Sin embargo, en general, creo que el impulso y los procesos de pensamiento fuertemente arraigados que respaldan las bases de datos de relaciones dificultan el cambio de las personas. Actualmente, la profesión de DB está entrenada casi exclusivamente en teoría relacional haciendo que sus profesionales de DB estén muy interesados en evitar OODB y la academia les enseña teoría de DB a los profesionales casi exclusivamente en relación.
Hasta grandes DBA corporativos y profesores de la corriente principal y el plan de estudios y la formación de personal más allá de los desarrolladores preparados para OODB administrado, siento que es poco probable que atraiga a masas sin importar cuán bueno sea desde el punto de vista del desarrollo.
Creo que es porque las "bases de datos de objetos" resuelven un problema que (casi) nadie realmente tiene. Para la persistencia simple de gráficos de objetos, la serialización integrada en la mayoría de los entornos OO es "lo 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 demasiado para el uso de RDBMS), realmente no hay ninguna necesidad de estas herramientas.
"Creo que es porque las" bases de datos de objetos "están resolviendo un problema que (casi) nadie realmente tiene". No creo que este sea el caso: mire la gran cantidad de proyectos ORM en uso para combatir el desajuste de la impedancia. –
Ese es mi punto. Los sistemas ORM manejan la coincidencia entre la capa OO y la representación de la base de datos lo suficientemente bien como para que no se perciba que una base de datos de objetos "pura" agrega mucho valor. Además, puede contratar fácilmente a alguien para administrar una base de datos SQL, pero los expertos en cualquier OODB son mucho más escasos. –
Creo que las bases de datos de objetos son una solución que busca un buen problema, y estoy de acuerdo con Mark Bessey. – thomasrutter
RDBMs (construidos sobre una sólida base teórica, han estado en el mercado por mucho más tiempo, pueden modelar datos con más fidelidad que los OODB en muchos casos, pueden ser utilizados por más DBA que OODB). Esa es una razón en forma de una tupla relacional.
select * from nice –
Creo que hay dos razones filosóficas.
Primero, las personas tradicionalmente tienden a separar la persistencia de la funcionalidad real. Una vez que quitas la "vida" de un objeto y lo mantienes principalmente para la persistencia, se convierte en un registro, y luego hay una tendencia a tratarlo como un objeto de datos "sin vida".
A continuación, 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á empezando a desaparecer. Por ejemplo, utilizo 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 hace de manera eficiente.
Bueno, es extraño ¿no? Existe un impulso hacia el diseño impulsado por el dominio como el cenit del análisis y diseño orientado a objetos, y existen patrones empresariales para aprovechar los sistemas ORM para persistir en nuestros objetos. Simplemente tiene sentido para mí que si su aplicación DISEÑO está orientada a objetos y enfocada en el dominio, un OODB beneficiará en gran medida su aplicación.
Además de los problemas relacionados con la madurez y la adopción, desde una perspectiva filosófica, un OODB parece beneficioso o una aplicación de OO. no tener que mantener esa capa de mapeo para principiantes;)
Pero fíjate, si no estás haciendo un diseño de disco de dominio y usas objetos como objetos de datos y como tus procesos almacenados, entonces realmente no vas a conseguirlo;)
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 de desestructurar los datos en un conjunto de instancias de tablas atómicas que se pueden volver a ensamblar en diferentes estructuras (generalmente con clases) sin alterar la integridad de los átomos.
Las bases de datos son algo análogas a hexahexaflexagons.
Excepto que eso no funciona. Las bases de datos relacionales son la fuente de todos los problemas de datos: hasta el 30% de todos los registros en las bases de datos relacionales contienen errores –
Las decisiones de alta tecnología no son tomadas por personas con conocimientos técnicos. Las empresas que utilizan bases de datos relacionales emplean a muchas personas que se sienten amenazadas por OODB y, por lo tanto, evitarán aprender sobre ellas.
Creo que es porque los grandes como Oracle han estado invirtiendo en bases de datos relacionales mientras que el movimiento orientado a objetos estaba cobrando impulso ... puede ser que se convertirán en la corriente principal si Oracle/Microsoft invierte en él a lo grande ... lo que parece poco probable porque no tienen una buena razón para hacerlo ... simplificará la vida de muchos programadores ... ¡pero "hacer que los programadores sean más simples" no es una muy buena meta comercial para ellos!
Bueno, Oracle tiene su propia base de datos NoSQL mientras hablamos ... – cseder
El motivo de la adopción lenta 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 puras ahora se encuentran 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 bases de datos, aunque esto se está corrigiendo 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 los lenguajes de consulta especializados para recuperar y manipular los datos en la tienda. Esto es un obstáculo 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 ahora tienen soporte para Diseño orientado a objetos, además tenemos envoltorios como ORM que muchos usan para "evitar" los problemas de las bases de datos relacionales que no están disponibles en el lenguaje de programación de elección.
Pero estos problemas existen principalmente en entornos corporativos. Como las bases de datos integradas en dispositivos pequeños, como el 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 de Language le permite activar los atributos de Object y almacenarlos fácilmente en el RDBMS y recuperar objetos de manera similar no es un gran problema. Aún faltan las bases amplias y sólidas que dificultan el uso de OODBMS para implementarse.
Actualmente estoy pensando en hacer esto como mi proyecto de fin de máster para proporcionar un marco general para OODBMS que admita casi todos los componentes que se utilizan comúnmente en RDBMS de hoy día, proporcionando así un DBMS estructurado no lineal. Mientras estudiaba, me encontré con un proyecto llamado db4o que es un enfoque (implementado) de usar OODBMS para Java y .NET solamente, por lo que esta podría ser otra razón de la falta de generalidad para todos los tipos de plataformas e idiomas.
http://www.odbms.org –
Creo que esta es http://en.wikipedia.org/wiki/Begging_the_question – Goran
+1 marxidad Los punteros son MALOS en los modelos de datos ... El modelo OO es muy parecido el viejo modelo de red, que no solo ha demostrado ser teóricamente inferior al modelo relacional, sino también un dolor para su uso en la práctica. Es extraño cómo los modelos de datos fallidos (jerárquico -> XML, red -> OO) siguen resucitando. Para mí, no aprender del pasado es una tontería, parece una pérdida de células preciosas del cerebro humano. –