database-design - relacional - orm ventajas y desventajas

Base de datos orientada a objetos: por qué la mayoría de las empresas no los usan (9)

Al haber trabajado para una empresa de bases de datos orientadas a objetos en el pasado ( www.objectstore.com ), y actualmente, creo que tengo una idea clara de lo que los hace geniales y de lo que los hace no tan geniales.

Estupendo:

Sin desajuste relacional de objetos. Si desea almacenar el objeto x en la memoria en una tienda persistente, ObjectStore puede hacerlo con garantías casi en tiempo real. Nuestro producto ha sido utilizado por muchas compañías para cumplir con requisitos de tiempo brutales que serían difíciles con bases de datos de relaciones o motores ORM.

No hay desajuste relacional entre objetos: se desarrolla en objetos, se piensa en objetos, se almacena en objetos.

No tan genial:

ORM: los administradores relacionales de objetos han hecho que las bases de datos Object sean irrelevantes

Evolución del esquema: cambie una clase para agregar un campo, y ahora debe transformar una base de datos COMPLETA. ObjectStore se ha vuelto más inteligente sobre esto a través de los años, pero sigue siendo un punto doloroso para muchos OODBMS.

Malo:

Soporte de herramientas: esto es lo que hace que OODBMS no sea un comienzo para la mayoría de los lugares. Hoy todos pueden tomar Crystal Reports o Access o Excel y generar una gran cantidad de informes. Con un OODBMS, tendría que construir esta lógica a través de un programador, y todos sabemos qué tan rápido es probable que suceda cuando necesita que su informe de presupuesto tenga en cuenta algún parámetro xyz que no pensó en el momento del diseño.

Las herramientas explican por qué OODBMS falló en el mercado. No superioridad técnica ni compatibilidad con el rendimiento o el lenguaje (ObjectStore es compatible con C ++ / Java / .Net y tiene compatibilidad con COM para admitir cualquier idioma IDispatch como VB, Perl, etc.).

Así que he dicho algunas cosas despectivas aquí, particularmente sobre un producto que realmente me gusta. Pero ObjectStore es increíble en tareas muy específicas, pero una mala elección para construir una aplicación web. Aunque en un momento dado, estaba impulsando el backend de administración de inventario para Amazon.com .

Soy bastante nuevo en la programación (acaba de terminar la universidad).

Se me ha pensado en los últimos 4 años sobre el desarrollo orientado a objetos y las numerosas ventajas de este enfoque.

Mi pregunta es

¿No es más fácil usar una base de datos orientada a objetos pura en aplicaciones de desarrollo?

¿Por qué la base de datos orientada a objetos no es tan difusa como relacional?

Desde mi punto de vista tiene sentido usar la base de datos OO, esta última evitará la construcción numerosa necesaria para el mapeo de objetos complejos en las tablas.

Como dices, estás recién egresado de la universidad y has sido adoctrinado intensamente en The One True (orientado a objetos). Si, por otro lado, hubiera aprendido programación declarativa, diseño de bases de datos y teoría de conjuntos, se daría cuenta de que el modelo relacional es un enfoque perfectamente adecuado, bien fundamentado en teoría, mientras que OO es un enfoque más pragmático que se inventó principalmente en la industria en lugar de la academia Da la casualidad que la investigación y el desarrollo más interesantes sobre problemas de bases de datos están siendo realizados por personas con más experiencia en matemáticas, para quienes el modelo relacional es la forma más natural de trabajar con datos. Como resultado, los RDBMS tienden a ser más estables, escalables y confiables que sus homólogos orientados a objetos. Las bases de datos orientadas a objetos, al igual que XML, a menudo se utilizan en un intento desacertado para hacer que los datos se ajusten a los programas que lo usan, en lugar de al revés.

Disculpas por no poder agregar esto como un comentario en el lugar donde realmente debería aparecer.

Pero lo siguiente constituye un ataque personal contra mí, e invoco mi derecho a responder.

Aunque estoy de acuerdo con usted en la práctica, no estoy de acuerdo con usted en espíritu, creo que usted es a quien le han lavado el cerebro para creer que la manera establecida es la única (quizás pongo palabras en su boca).

FWIW, ciertamente no he sido "lavado de cerebro" en lo que probablemente puedas llamar "la creencia religiosa relacional". El lavado de cerebro es cuando un tutor dice algo, y el estudiante ciegamente y sin cerebro lo acepta como la única verdad sin ningún tipo de pensamiento crítico. De hecho, nunca me han enseñado el modelo relacional. De hecho, he tenido que descubrir todo eso por mi cuenta. Es un hecho registrado que he expresado críticas severas a las opiniones de Date sobre el tema de la actualización de la vista. (corrección: "fue" una cuestión de hecho registrado. La página parece haber sido eliminada del sitio donde se publicó. Probablemente tiene todo que ver con el hecho de que Date ha abandonado la posición de actualización de vista que critiqué).

Por lo tanto, creo que tengo todos los motivos para decir que cualquier afirmación de que alguna vez me dejé lavar el cerebro es totalmente propositiva. Usted es libre de pensar lo que quiera, pero si expresa públicamente cualquier opinión personal gratuita y basada en nada, espero que usted también sea lo suficientemente adulto como para verlos refutados por los hechos y admitirlo.

La razón por la cual los modelos jerárquicos y de red han sido reemplazados por la RM ha sido ampliamente documentada en bibliotecas enteras llenas de libros sobre el tema. Te invito a inspeccionarlos cuidadosamente.

En cuanto a que "el valor clave se está apoderando del mercado": eres completamente libre de tomar "la opinión más común del mercado" (es decir, la mediocre mayoría de los tontos demasiado perezosos para pensar que son bastante felices dejar que ellos (y sus opiniones) sean guiados por los Ellisons y Gateses y Jobses de este mundo) como el criterio principal de lo que es valioso y lo que no lo es. Personalmente creo que es una tontería, pero esa es solo mi opinión personal. Copio y pego aquí algunas observaciones hechas por alguien que enfrenta los horrores de EAV y Key-value casi todos los días de su vida profesional:

Trabajo en una aplicación que utiliza el siguiente "modelo EAV" (al menos, el "modelo EAV" como lo entiendo) para muchas tablas lógicas, pero no todas:
R1 {EAV_RELVAR_NAME*, ... } R2 {EAV_RELVAR_NAME*, ATTRIBUTE_NUMBER*, COLUMN_NAME, DATA_TYPE, ...} R3 {EAV_RELVAR_NAME, ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3, ..., ATTRIBUTE50}
En el que uno podría ver los siguientes valores:
R1 { {''STATE_CODES''} } R2 { {''STATE_CODES'', 1, ''STATE_NAME'', ''CHAR(30)''} , {''STATE_CODES'', 2, ''STATE_CODE'', ''CHAR(2)'' } ...} R3 { {''STATE_CODES'', ''ALABAMA'', ''AL''} , {''STATE_CODES'', ''ALASKA'', ''AK''} ...}
Básicamente, "relvars EAV" se crean / alteran / eliminan con inserciones / actualizaciones / eliminaciones en R1 y R2 (en comparación con DDL). Esta es una versión recortada de nuestro modelo general: hay columnas adicionales en R1 y R2 para especificar eav-primary-keys, eav-foreign-keys, reglas comerciales, etc ... todo impuesto por el código de procedimiento incorporado en el "uno verdadero front end "del modelo.
Esta mañana, tuve acceso a una prueba de más de 20 horas hombre que resultó cuando el Sistema A pensó que CODE_XYZ estaría en ATTRIBUTE2, pero el Sistema B en realidad lo definió en ATTRIBUTE3 ... Tuve que reírme por el hecho de que estaba medio escuchando a la conversación, y medio leyendo el discurso de este grupo sobre EAV.
El mes pasado, tuve que poner una actualización de emergencia (16 horas-hombre más "malas notas" para la aplicación) para cambiar ATTRIBUTE16 de "MAYO 2010" a "MAYO-2010" para 430 puntos de datos ingresados por el usuario.
Aproximadamente el 5-10% de nuestros lanzamientos de código se acompañan con "limpiezas de errores de tiempo de ejecución de lunes por la mañana", porque los EAV_RELVARs no estaban codificados en R1 o R2 idénticamente en producción como se hizo en prueba / desarrollo (ambos códigos de aplicación y DDL se migran con control de software estricto de versiones ... nuestro modelo EAV no está ligado a tal burocracia ya que "permite" a los desarrolladores configurar sus EAV de forma autónoma en desarrollo, prueba y producción).
El año pasado, utilicé un sólido software de replicación de ajuste de 3 semanas exclusivamente para lidiar con la falta de una clave principal en R3.
Una vez tuve que disculparme por la imposibilidad de poner un índice en ATTRIBUTE4 de EAV_RELVAR_NAME_x, ya que estaba estropeando el rendimiento de un programa diferente que usaba EAV_RELVAR_NAME_z.
Hace dos años, después de varios años hundiendo cientos de horas ajustando constantemente las consultas complejas que necesitaban unirse a R3, finalmente pasé 3 meses dividiendo R3 en cientos de particiones físicas (una por EAV_RELVAR_NAME), para darle al optimizador de DBMS las estadísticas necesitaba ver que había, por ejemplo, 50 ''STATE_CODES'' y 200,000 ''LOCATION_CODES''. Me felicitaron por la ingeniosa solución, aunque todos perdieron la ironía cuando señalé que, con este cambio, habría una nueva política en la que agregar un nuevo EAV_RELVAR_NAME implicaría ejecutar un script que agregara una partición asociada a R3 (sí , con DDL).
Mis clientes quieren una nueva interfaz para cargar datos en R3 para uno de sus EAV_RELVAR_NAME (mientras aplican todas las restricciones y seguridad apropiadas), y quieren saber por qué la construcción tardará 4 meses.
A menudo señalo que podría reescribir todo el sistema EAV de una manera que era superior en todos los sentidos, utilizando el DDL dinámico contra el diccionario de datos en lugar de DML contra R1 y R2, pero siempre estoy informado de que estamos "comprometidos". "a este enfoque (hubo un gasto inicial de 7 cifras para construirlo, y tendríamos que reescribir el 98% de nuestra base de código para cambiar a tablas independientes), y que los fines no justifican los medios .

Si realmente cree que tales escenarios son una mejora sobre el RM, entonces, por supuesto, adelante. No me culpes por lo mucho que duele cuando finalmente golpees tu cabeza contra la pared.

Hace diez años analicé el diseño de bases de datos orientadas a objetos (para un proyecto personal) y descubrí que no eran muy buenos para realizar ciertos tipos de búsquedas de forma fácil o rápida (por ejemplo, "buscar a todas las personas cuyo apellido comienza con ''S''), aunque, por supuesto, hay muchas consultas relacionales que no son necesarias en una base de datos orientada a objetos. Además, en ese momento, la base de datos orientada a objetos no estaba realmente preparada para una implementación a gran escala (que no era una preocupación mía). cree que los más nuevos han solucionado ese problema, pero todavía hay una gran cantidad de intertia y buenos ORM que hacen que el uso de una base de datos relacional sea relativamente fácil.

Sin embargo, hay un movimiento que se aleja de las bases de datos relacionales, vea el movimiento NoSQL . Creo que Google no usa una base de datos relacional (pero tampoco está orientada a objetos, sino algo propiedad y distribuida).

La base de datos no se trata solo de almacenar y recuperar objetos; de lo contrario, OODB y Document DB se habrían apoderado del mundo. Otros contextos / aspectos de uso incluyen:

Agregación de datos y procesamiento / manipulación complejos de datos a granel. RDBMS son muy buenos en esto.
Otro aspecto importante es la concurrencia / aislamiento (es decir, las transacciones). RDBMS son muy maduros en esta área.
Otro aspecto es la indexación para garantizar consultas rápidas.
Otro aspecto, como el de "Chris Kaminski" mencionado anteriormente, es poder evolucionar su esquema a lo largo del tiempo a la vez que se preservan los datos.

Finalmente, hay un poco de inercia en la industria, con grandes vendedores que no están dispuestos a apostar dinero por algo que los clientes no están dispuestos a pagar, y los clientes esperando al margen hasta que los principales proveedores se unan al juego.

No hay una buena razón para esto, especialmente con el aumento del uso de ORM (Active Record) y los problemas del mapeo. Las bases de datos orientadas a objetos son más rápidas y mejores de muchas maneras. La razón para no ser popular es la necesidad. Hasta el momento, RDBMS ha estado haciendo un buen trabajo y en las grandes empresas, el mayor dolor se llama ''migración''. Como con la mayoría de la tecnología, la necesidad del usuario es el objetivo principal, y la Orientación del Objeto no suele ser el punto de venta. La velocidad tal vez, pero el hardware costoso y la sintonización RDBMS comprobada también pueden lograr el rendimiento.

También las personas que son expertas en esta área, tendrían que ser entrenados de nuevo (lo que cuesta mucho dinero). Sin mencionar a todos los consultores caros que aprendieron mal PL / SQL ...

Yo diría, ser un primer motor. Como dijo Mahatma Ghandi, sé el cambio que quieres ver. Es curioso, me acabas de dar ganas de buscar un OO-DB de código abierto.

No hay ventajas de utilizar este enfoque cuando ya tienes una base de datos relacional que tiene muchos gigabytes de tamaño y ya almacena 20 años de datos y tiene cientos o miles de tablas. Este es el mundo real de muchas aplicaciones comerciales. Las bases de datos se utilizan para mucho más que el mapeo de objetos de su aplicación particular. La base de datos seguirá existiendo mucho después de que desaparezcan las aplicaciones que escribes. Muerde la bala y aprende bases de datos relacionales, ya que no van a desaparecer en ningún momento en los próximos 100 años.

Otro problema es el soporte de idiomas. ¿Qué pasa con los idiomas que no están orientados a objetos? Una buena base de datos debe ser accesible para todos, sin importar el idioma. Es por eso que muchas bases de datos específicas de un idioma fallan, porque su mercado es solo personas de ese idioma.

También está el factor de migración. Los usuarios más grandes de MySQL son usuarios a largo plazo. La migración a un sistema de base de datos completamente nuevo con un diseño fundamental completamente diferente con un gran diseño existente sería muy costoso y ofrecería poca recompensa.

Una razón por la cual la adopción de bases de datos orientadas a objetos es tan lenta es porque no hay muchas alternativas de OpenSource escalables. Para RDBMS hay, por ejemplo, MySQL (Oracle posee ahora), PostgreSQL y muchos más.

Otro problema es que, al menos para Java, las API estándar para acceso RDBMS JDBC y JPA para la parte ORM tienen compañías más grandes atrás y son más conocidas. JDO para acceso a bases de datos orientadas a objetos es un estándar, pero no tan popular.

Las bases de datos orientadas a objetos tienen, en la mayoría de los casos, un bloqueo de API o de idioma más fuerte que RDBMS, que es otra razón por la cual empresas más grandes con múltiples plataformas e inversiones de idioma permanecen con RDBMS.

Para mí, las bases de datos OpenSource OO populares serían una razón para invertir más tiempo en probarlas.