database - relaciones - ¿Por qué las bases de datos orientadas a objetos no han tenido éxito(todavía)?
que es una bdoo (14)
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.
¿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.
Creo que es porque las "bases de datos de objetos" están resolviendo 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 "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 hay dos razones filosóficas.
En primer lugar, 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 comienza 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.
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.
Los RDBM (basados en una sólida base teórica, han estado en el mercado durante mucho más tiempo, pueden modelar datos con mayor fidelidad que los OODB en muchos casos, pueden ser utilizados por más DBA que por OODB). Esa es una razón en forma de una tupla relacional.
Si puedo amplificar 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.
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 principal razón por la que OODB no se ha consolidado de manera espectacular es por 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 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 que los DBA grandes y corporativos, los profesores principales y el plan de estudios y el personal que trabaja más allá de los desarrolladores estén preparados para administrar OODB, siento que es poco probable que se vea un gran atractivo, sin importar cuán bueno sea desde el punto de vista del desarrollo.
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.
Las decisiones costosas sobre tecnología no las toman 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 habían estado invirtiendo en bases de datos relacionales mientras que el movimiento orientado a objetos estaba cobrando impulso ... puede ser que se conviertan en la corriente principal si Oracle / Microsoft invierten en él a lo grande ... lo que parece poco probable porque no lo hacen No hay una razón fuerte para hacerlo ... simplificará la vida de muchos programadores ... ¡pero "hacer que los programadores vivan más simplemente" no es un muy buen objetivo comercial para ellos!
El motivo de la adopción lenta de OODB se basa principalmente en algunos factores clave que hacen que las bases de datos SQL relacionales sean más populares y / o más apropiadas. Mientras que las bases de datos orientadas a objetos puros están 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 bases 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, confían en el lenguaje de programación o en los lenguajes de consulta especializados para recuperar y manipular los datos almacenados. 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 relacionales basadas en SQL ahora admiten el 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 su 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 nos depara el futuro?
La serialización proporcionada por la mayoría de los idiomas le permite ajustar los atributos del objeto y así 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 Master Thesis para proporcionar un marco general para OODBMS que soporte 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 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.
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 sería beneficioso o una aplicación OO. no tener que mantener esa capa de mapeo para principiantes;)
Pero mira, 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;)
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 depósito de datos, por ejemplo, o simplemente ser consultados por administradores de sistemas, etc.