database - soporta - optimizar consultas lentas mysql

¿Cuáles son los pros y los contras de las bases de datos de objetos? (7)

Contras:

No puede ser utilizado por programas que tampoco usan el mismo marco de trabajo para acceder al almacén de datos, por lo que es más difícil de usar en toda la empresa.
Menos recursos disponibles en línea para bases de datos no basadas en SQL
Sin compatibilidad entre los tipos de bases de datos (no se puede cambiar a un proveedor de db diferente sin cambiar todo el código)
Las versiones son probablemente un poco perras. Supongo que agregar una nueva propiedad a un objeto no es tan fácil como agregar una nueva columna a una tabla.

Hay mucha información disponible sobre mapeadores relacionales de objetos y cómo evitar el desajuste de impedancia, todos los cuales parecen ser puntos discutibles si uno fuera a usar una base de datos de objetos. Mi pregunta es por qué no se usa con más frecuencia? ¿Es por motivos de rendimiento o porque las bases de datos de objetos hacen que sus datos sean propiedad de su aplicación o se debe a algo más?

Una objeción a las bases de datos de objetos es que crea un acoplamiento estrecho entre los datos y su código. Para ciertas aplicaciones esto puede estar bien, pero no para otros. Una buena cosa que le ofrece una base de datos relacional es la posibilidad de poner muchas vistas en sus datos.

Ted Neward explica esto y mucho más sobre OODBMSs mucho mejor que esto.

Sören

Todas las razones que indicó son válidas, pero veo que el problema con OODBMS es el modelo de datos lógicos. El modelo de objeto (o más bien el modelo de red de los años 70) no es tan simple como el relacional, y por lo tanto es inferior.

He estado usando db4o que es un OODB y resuelve la mayoría de los inconvenientes enumerados:

Familiaridad: los programadores conocen su idioma mejor que SQL (ver consultas nativas)
Rendimiento: este es muy subjetivo, pero puedes echar un vistazo a PolePosition
Soporte y madurez del proveedor: puede cambiar con el tiempo
No puede ser utilizado por programas que no usan el mismo framework. Hay estándares OODB y puede usar diferentes frameworks
El control de versiones es probablemente un poco perverso. ¡El control de versiones es realmente más fácil !

Los profesionales que me interesan son:

Consultas nativas: Db4o te permite escribir consultas en tu lenguaje estático escrito para que no tengas que preocuparte por escribir mal una cadena y encontrar datos que faltan en el tiempo de ejecución.
Facilidad de uso: la definición de la lógica de buissiness en la capa de dominio, la capa de persistencia (mapeo) y finalmente la base de datos SQL es, sin duda, una violación de DRY. Con OODB defines tu dominio donde pertenece.

Estoy de acuerdo - OODB tiene un largo camino por recorrer pero se van. Y hay problemas de dominio que están mejor resueltos por OODB,

jodonnel, no veo cómo el uso de las bases de datos de objetos acopla el código de la aplicación a los datos. Todavía puede abstraer su aplicación del OODB mediante el uso de un patrón Repositorio y reemplazarlo con una base de datos SQL respaldada por ORM si diseña correctamente las cosas.

Para una aplicación OO, una base de datos OO proporcionará un ajuste más natural para objetos persistentes.

Lo que probablemente sea cierto es que relacionas tus datos con tu modelo de dominio, ¡pero entonces ese es el quid!

¿No sería bueno tener una sola forma de ver los datos, las reglas de negocio y los procesos usando una vista centrada en el dominio?

Entonces, un gran profesional es que un OODB coincide con la forma en que se diseñan las aplicaciones de software orientadas a objetos más modernas y de nivel empresarial, no hay un esfuerzo adicional para diseñar una capa de datos usando un diseño diferente (relacional). Más barato para construir y mantener, y en muchos casos un mayor rendimiento general.

Contras, solo falta general de madurez y adopción, reconozco ...

No tiene nada que ver con el rendimiento. Es decir, básicamente, todas las aplicaciones funcionarían mejor con un OODB. Pero eso también dejaría a muchos DBA sin trabajo / teniendo que aprender una nueva tecnología. Aún más personas estarían sin trabajo corrigiendo errores en los datos. Es poco probable que los OODB sean populares entre las compañías establecidas. Gavin parece estar completamente despistado, un mejor vínculo sería Kirk

Familiaridad. Los administradores de las bases de datos conocen conceptos relacionales; objetos, no tanto.
Actuación. Se ha comprobado que las bases de datos relacionales escalan mucho mejor.
Madurez. SQL es un lenguaje potente y desarrollado durante mucho tiempo.
Soporte del vendedor Puede elegir entre muchas más herramientas de primera parte (servidores SQL) y de terceros (interfaces administrativas, asignaciones y otras clases de integración) que en el caso de OODBMS.

Naturalmente, el modelo orientado a objetos es más familiar para el desarrollador y, como usted señala, le ahorraría uno de ORM. Pero hasta ahora, el modelo relacional ha demostrado ser la opción más viable.

Consulte también la pregunta reciente, Bases de datos orientadas a objetos frente a relacionales .