¿Son las bases de datos relacionales de objetos el futuro?

Answer 1

Las características de ORDBMS han estado disponibles experimentalmente durante más de 20 años, pero no han sido ampliamente adoptadas.

Compare con la tecnología que satisface una necesidad crucial, que puede ponerse al día con mucha rapidez, por ejemplo, marcos de aplicaciones web, AJAX, marcos de Javascript, virtualización o aplicaciones móviles. Estas son todas las tecnologías que hacen que los desarrolladores sean más productivos. Esto es lo que ayuda a la adopción por la tecnología.

Las características de ORDBMS en la capa de base de datos hacen que la base de datos sea más compleja y hacen que los desarrolladores sean menos productivos. Tienen suficientes métodos de modelado de datos de aprendizaje de dolores de cabeza para el RDBMS simple, y la adición de tipos estructurados y la herencia en su caja de herramientas de modelado de datos solo lo hace más difícil. Los desarrolladores incluso aceptarán tendencias tecnológicas que sean menos eficientes para la computadora, si les ayuda a realizar el trabajo más rápido.

Es por eso que la tendencia es la opuesta a ORDBMS: la tendencia es preferir una capa de base de datos más simple y poner más lógica en el código de la aplicación, donde se puede escribir, probar, depurar y mantener de la misma manera que el resto del código. en un proyecto.

Esta tendencia encaja bien con la popularidad de las bases de datos NoSQL, que en la mayoría de los casos ni siquiera admiten tipos de datos o restricciones como lo hace un RDBMS. Han hecho que la base de datos sea menos inteligente y han puesto más inteligencia en el código de la aplicación. La base de datos se trata como un grupo de datos relativamente pasivo.

Bajo estas condiciones, no hay ningún incentivo para que ORDBMS crezca en popularidad.

Answer 2

No sé la respuesta, pero señalaría una observación. Me doy cuenta de que las herramientas, el IDE, alienta el tipo de desarrollo incorrecto. Estoy pensando específicamente en el soporte Entity Framework de Visual Studio. No tengo mucha experiencia con otras herramientas de desarrollo relacional de objetos aparte de hacerlo todo a mano con JEE y .NET. Si sigue la metodología de desarrollo fácil que permite Visual Studio, lo cual es bastante bueno, creará una base de datos que no satisfará sus necesidades cuando sea el momento de ponerla en producción. Microsoft ha cometido este mismo tipo de error con otros paradigmas de desarrollo en el pasado. Es un truco de marketing diseñado para reducir la barrera del desarrollo. ¿Cuántos de nosotros recordamos al antiguo diseñador de Visual Studio antes de usar XML? Microsoft tardó 6 años en hacer su uso práctico convirtiéndolo en una representación XML, antes de que solo fuera un juguete. Entonces, si arrastra y suelta y encuentra el IDE creando tablas en la base de datos, eso es un signo de que las cosas van mal.

Un esquema de base de datos relacional, específicamente el tipo de base de datos OLTP, debe ser diseñado por alguien que sepa lo que está haciendo si se va a utilizar. Trabajar con Entity Framework y MVC en Visual Studio y, de hecho, construir su esquema es suicida, en mi opinión, y usted está construyendo algo de todos modos que está demasiado escrito en piedra. Debe haber vistas y procedimientos almacenados entre su Modelo de entidad y las relaciones (tablas). Un modelo de entidad nunca debe reflejar la arquitectura de la tabla, excepto en algunos casos.

Answer 3

Yo no apostaría en ello. Durante los más o menos veinte años que he estado trabajando con RDBM, he escuchado la línea un buen número de veces, “X reemplazará a RDBMs”. Hasta ahora ninguno de ellos se ha hecho realidad. A veces, algunas ideas se han incorporado más tarde a las RDBM, pero en general estos nuevos juguetes se habrían desvanecido. Creo que escuché por primera vez hace más de una década que los ORM reemplazarían a los RDBM. Aquí estamos una década después haciendo la misma pregunta.

Ahora, después de haber hecho una buena cantidad de programación de VB y C # (aunque soy principalmente un DBA) ciertamente puedo ver el atractivo. Los objetos a menudo modelan bien el mundo real. Pero el mundo real puede ser un lugar desordenado. Un RDBM es un lugar matemáticamente sólido, consistente y, como tal, MUY bueno en lo que hace, almacenando datos que, como relaciones (y la mayoría de los datos lo hacen). Codd fue un genio y es una pena que más personas no lean sus ideas originales.

Dicho esto, los diseños que no son RDMB como ORM y No_SQL y similares tienen su lugar. No creo que desaparezcan, pero no reemplazarán a las RDBM.

Answer 4

No, no creo que las bases de datos objeto-relacionales sean el futuro.

Esto es solo una conjetura y se basa en una opinión y un estilo sesgados personales.

Principalmente, trabajo con problemas de datos duros y me parece que la conversión a una metodología de programación funcional / de procedimiento casi exclusiva es muy útil si no es clave. Además de la programación funcional / de procedimientos, tengo un gran sesgo de servicio SOA / micro. Para las cosas que implemento, ahora encuentro que OO es una forma menos deseable de pensar en estas cosas cuando se enfoca en problemas de datos difíciles.

Nota: Me siento perfectamente cómodo al hacer que los servicios entreguen datos a una capa de presentación en múltiples formatos. Uno de esos formatos puede ser una presentación amigable OO. Sospecho que la programación de la capa de presentación seguirá favoreciendo la metodología OO la mayor parte del tiempo. OO parece tener más sentido en ese dominio, aunque estoy menos calificado para hablar sobre metodologías de presentación.

Para aplicaciones pequeñas a medianas donde los datos no son tan importantes, sospecho que estas cosas no importan. Uno podría usar archivos planos de manera deficiente y aún tener una aplicación funcional exitosa. Para este tipo de cosas, si hace feliz a un desarrollador usar OO de principio a fin, creo que está bien siempre que se satisfagan todas las necesidades comerciales. Me interesan más las aplicaciones que hacen cosas difíciles donde los problemas de negocios requieren que los datos se traten con el mayor cuidado posible.