Programación unificada y consulta de base de datos [cerrado]

Considere un tutorial común para lenguajes de programación orientados a objetos como C ++ o Java: cree un sistema de procesamiento de pedidos simple con objetos que representen cuentas, pedidos, artículos, etc. (o algo más o menos equivalente). Tiene perfecto sentido intuitivo, pero el elefante en la mesa del comedor es que no es real porque son objetos en memoria; en un sistema real, las cuentas, los pedidos, etc. en realidad no viven en la memoria , sino en una base de datos, con la representación de la memoria solo un espejo de corta duración.

Podría escribir mucho código usted mismo para leer y escribir desde la base de datos, pero eso es tan tedioso y propenso a errores que en realidad nadie lo hace.

Todos terminan usando un ORM, pero son tan problemáticos en sí mismos que un periódico famoso los llama 'el Vietnam de nuestra industria'.

No creo que sea una falta de coincidencia entre el objeto y la relación tanto como una falta de coincidencia entre el lenguaje de programación y la base de datos que son cosas separadas que no se conocen entre sí . Conjetura: la solución es tener un solo lenguaje que sea tanto el lenguaje de consulta de programación como de base de datos, lo que a su vez requeriría que el tiempo de ejecución del lenguaje también sea la base de datos, y el compilador JIT también sea el optimizador de consultas.

Así que ese es el resumen de los problemas que veo. Mi pregunta es, ¿alguien tiene todavía?

1. Realmente construido un sistema tan unificado

2. Intenté pero no logré construir un sistema tan unificado

3. Escribe cualquier cosa sustancial sobre el tema de cómo construirías tal, o por qué o por qué no

4. ¿Se le ocurrió una forma alternativa de resolver el problema?

Esta es mi opinión. Si bien veo de dónde vienes, no puedo ver que suceda desde la perspectiva del diseño.

La persistencia de datos es un tema extremadamente complejo. Y también lo son los lenguajes de programación. La combinación de los dos resultaría en una explosión de complejidad. Se necesitaría mucho esfuerzo para hacer que ambos sean lo suficientemente buenos para que las personas realmente quieran usarlo. Creo que MUMPS ya mencionado es un buen ejemplo. O bien, puede ver varias variantes de SQL que tienen el idioma completo atornillado sobre ellas. Pueden ser utilizables, pero no creo que la gente los use voluntariamente.

Entonces, separarlos es una forma clara de cómo resolver esta complejidad. Además, al no unirlos, permite que ambos cambien y evolucionen con el tiempo. Por ejemplo, SQL es antiguo y no cambió mucho desde que se creó. Pero los idiomas utilizados para ejecutar aplicaciones cambiaron drásticamente durante el mismo período. Y ahora, sucede lo contrario. Los idiomas permanecen mayormente iguales mientras se cambian y evolucionan las bases de datos.

La implementación en tiempo de ejecución es otro problema. La combinación de ambos significaría que tanto la base de datos como la aplicación o el servidor web tendrían que ejecutarse en un mismo proceso. Esto es extremadamente limitante, tanto desde la perspectiva del mantenimiento como desde la capacidad de ejecutarlos en computadoras separadas o en relaciones de muchos a uno.

Dividir los dos en módulos separados con API clara entre ellos es la mejor manera de mantener baja la complejidad y darle flexibilidad en las tecnologías que desea usar y cómo se implementan las piezas finales.

Parece que estás haciendo algunas suposiciones importantes. Por ejemplo, está asumiendo que todos están escribiendo en bases de datos relacionales. Ese simplemente no es el caso, hay muchos ejemplos de bases de datos de otros tipos (dbs de objeto, dbs de documento, etc.) que usan un lenguaje de programación nativo para escribir todo el código y gestionar la persistencia.

Por ejemplo, Db4O es compatible con Java y C #, ObjectDB en Java, VelocityDB en una variedad de lenguajes. Todos los controladores de MongoDB terminan haciéndote escribir cosas en tu lenguaje de programación nativo (extra si estás usando JavaScript, ya que eso significa que el shell también usa la misma sintaxis), y así sucesivamente.

Hay mucha discusión en varios lugares sobre qué motores de base de datos son mejores en qué contextos y por qué, demasiado para el alcance de esta respuesta, incluir una pregunta cerrada en este mismo sitio. El resultado es que cada uno de ellos está optimizado para diferentes cosas, y hasta hace poco SQL se consideraba una especie de 'mínimo común denominador' para las aplicaciones comerciales porque obtienes mucho gratis en términos de ACID y rendimiento (aunque ambos están cambiando recientemente a medida que cambian las arquitecturas y los requisitos).

También vale la pena señalar que en realidad hubo muchos tipos de enfoques "todo en uno" antes. Los lenguajes de mainframe a menudo tenían su propia lógica de persistencia incorporada, y hay lenguajes como Smalltalk que no diferencian en absoluto el código y los datos. De nuevo, a menudo son buenos para algunos casos de uso, pero no para todos.

1. Si (no yo) Se llamaba MUMPS .

2. De acuerdo con esto, esta antigua pregunta SE.SE , o este artículo , MUMPs no estaba muy bien diseñado. Pero sí se usó en la industria de la salud (y supongo que todavía hay sistemas existentes que lo usan), por lo que no es un fracaso total.

3. Seguramente encontrará información al respecto ahora que sabe qué buscar. Comience con el enlace de Wikipedia anterior.

4. Busque bases de datos orientadas a objetos, muchas de ellas son específicas del idioma. Intentaron abordar el desajuste relacional de objetos de formas más simples que los ORM.

De hecho, existen múltiples sistemas que unifican la base de datos y el lenguaje de programación en un solo entorno.

Smalltalk es probablemente el más cercano a lo que usted describe. Los objetos en la memoria se conservan en una "imagen", por lo que el entorno del lenguaje se puede utilizar una base de datos (objeto) de fábrica. Y la mayoría del lenguaje moderno tiene algún tipo de mecanismo de persistencia incorporado, lo que significa que los objetos en el entorno del lenguaje pueden persistirse y consultarse utilizando el lenguaje mismo.

Esto es muy conveniente para aplicaciones de un solo usuario. Pero el enfoque no escalará a múltiples usuarios, ya que necesitarán compartir el mismo espacio de memoria, lo que obviamente pone un límite a la cantidad de usuarios. Una solución escalable requiere un servidor de base de datos separado que gestione la concurrencia. Incluso entonces, hay múltiples bases de datos NoSql que se integran con un entorno de lenguaje específico y le permiten persistir y consultar objetos en el lenguaje mismo.

Desde el lado relacional de las cosas, tenemos lenguajes como T-SQL, que es un lenguaje de programación completo que es un superconjunto de SQL, por lo que las consultas y DML se pueden mezclar con lógica de procedimiento compleja arbitraria. Se han creado aplicaciones comerciales complejas utilizando T-SQL, por lo que esto es factible, pero la tendencia actual es la lógica empresarial de procedimiento fuera de la base de datos.

En estos casos, es muy elegante y conveniente tener la base de datos integrada con el lenguaje de programación y evitar el "desajuste de impedancia". Entonces, ¿por qué las personas todavía usan bases de datos relacionales separadas del entorno de programación e intentan conectarse con algún ORM-kludge?

Resulta que hay una serie de ventajas de tener datos y consultas separados de cualquier lenguaje y entorno de programación específico.

• Independencia de datos. En la mayoría de las organizaciones, múltiples aplicaciones acceden a los datos. Una tienda puede tener una base de datos utilizada por la interfaz web, por una herramienta de atención al cliente, un motor de informes, etc. Los datos en sí mismos suelen ser de larga duración, mientras que las aplicaciones van y vienen. El acoplamiento de los datos a un entorno de programación específico sería un bloqueo a un entorno de programación específico. Pero los lenguajes de programación van y vienen, mientras que los datos viven para siempre.
• Consulta ad hoc. Es extremadamente conveniente poder abrir una solicitud de base de datos y escribir una consulta. Si las consultas estuvieran estrechamente acopladas al entorno de programación, esta sería una tarea de programación y solo los desarrolladores podrían hacerlo.
• Evitar el bloqueo. Como SQL es un estándar, varios proveedores pueden proporcionar sistemas de administración de bases de datos que son más o menos intercambiables. Esto evita el bloqueo del proveedor y facilita la comparación de productos.
• Bajo acoplamiento. Tener una interfaz bien definida entre la capa de aplicación y la base de datos hace posible ajustar y optimizar la base de datos independientemente de la lógica de la aplicación.
• Interfaz compartida Dado que la interfaz de la base de datos es independiente de la lógica de la aplicación, se pueden utilizar herramientas estándar para la creación de perfiles, la replicación, el análisis, etc.

Es una muy buena pregunta que estaba procesando en mi cabeza muchas veces. Un ejemplo de una solución existente para resolver su problema es una base de datos gráfica ArangoDB en la que utiliza JavaScript (que se ejecuta en un motor interno) para escribir controladores que pueden generar páginas web completas. Los datos se pasan a / desde el almacenamiento utilizando JSON, por lo que se puede acceder de forma nativa en JavaScript y las consultas se realizan en un lenguaje de consulta incrustado. Entonces, este caso es un ejemplo de extender JavaScript para que se ejecute en la base de datos.

En la práctica, tales controladores no deben exponerse al público por razones de seguridad, ya que una falla en la configuración de la base de datos o un error provocará la exposición de sus valiosos datos al público.

En mi opinión personal, este es un buen enfoque y considerar si la base de datos admite un tipo de función de mapa / reducción que actualizará los datos agregados / índices de texto y otros datos consultados con frecuencia en tiempo real, agregando una capa de seguridad delgada en el medio (llámelo carga equilibrador) haría una aplicación funcional ejecutándose en una base de datos distribuida.

1. Realmente construido un sistema tan unificado

Sí, hice eso en Sciter .

El script de Sciter es un " JavaScript ++ " que tiene persistencia incorporada:

var ndb = Storage.open(pathname);
ndb.root = { ... root object ... };

Donde ndb.rootes normal Objeto en términos de JS. Todas sus propiedades y subobjetos accesibles desde él son persistentes, almacenados y recuperados en la base de datos cuando sea necesario, de forma transparente para el código:

ndb.root.accounts[2].firstName = "John";
var name = ndb.root.accounts[3].firstName;

Los datos se almacenan en la base de datos, ya sea en el ciclo GC, cuando no hay suficiente memoria, o en una ndb.commit()llamada explícita .

StorageLa clase está acompañada por la Indexclase - colecciones de objetos ordenados persistentes con claves únicas / no únicas.

El conjunto de características es similar a MongoDB u otras bases de datos NoSQL, pero la identificación no requiere ORM por separado: el acceso a la base de datos se realiza por medios puramente de script.

Estoy absolutamente a favor y no tengo idea de por dónde empezar. SQL puede ser brillante e imagino que sería genial tener todo ese poder y las garantías transaccionales directamente en su lenguaje de programación multipropósito (en lugar de tener que escribir consultas como colecciones de cadenas o usar, Dios no lo quiera, un ORM).

El único sistema que se acerca a su idea que conozco se llama aquameta (línea de etiqueta: "pila de desarrollo web integrada en PostgreSQL"; consulte https://github.com/aquametalabs/aquameta , http://aquameta.org ). Hay algunos videos de introducción que no son un poco menos locos que la idea en sí (youtube.com/watch?v=jz74upW7TN0, youtube.com/watch?v=cWGm9eYUYUk&t=29s, youtube.com/watch?v=xRoUQGUmiMg), y cuando digo loco, quiero decir que implementaron su propio editor y su propio sistema de control de versiones dentro de Postgres.

Creo que esta fue exactamente la razón de la invención de Microsoft de LINQ. Ha estado en uso de producción a gran escala durante varios años, por lo que es fácil encontrar literatura al respecto y reflexiones de experiencias del mundo real, tanto positivas como negativas. (La mayoría de las tiendas de desarrollo .net lo aceptan).

Un buen punto de partida en linq: https://docs.microsoft.com/en-us/dotnet/csharp/linq/