¿Las bases de datos y la programación funcional están en desacuerdo?

He sido desarrollador web durante algún tiempo y recientemente comencé a aprender algo de programación funcional. Como otros, he tenido algunos problemas importantes para aplicar muchos de estos conceptos a mi trabajo profesional. Para mí, la razón principal de esto es que veo que un conflicto entre el objetivo de FP de permanecer apátrida parece estar en desacuerdo con el hecho de que la mayoría del trabajo de desarrollo web que he realizado ha estado fuertemente vinculado a las bases de datos, que están muy centradas en los datos.

Una cosa que me hizo un desarrollador mucho más productivo en el lado de OOP fue el descubrimiento de mapeadores relacionales de objetos como MyGeneration d00dads para .Net, Class :: DBI para perl, ActiveRecord para ruby, etc. Esto me permitió mantenerme alejado desde escribir declaraciones de inserción y selección todo el día, y enfocarse en trabajar con los datos fácilmente como objetos. Por supuesto, aún podía escribir consultas SQL cuando se necesitaba su poder, pero de lo contrario se resumía muy bien detrás de escena.

Ahora, volviendo a la programación funcional, parece que con muchos de los marcos web FP como Links requieren escribir mucho código sql repetitivo, como en este ejemplo . Weblocks parece un poco mejor, pero parece usar una especie de modelo OOP para trabajar con datos, y aún requiere que el código se escriba manualmente para cada tabla en su base de datos como en este ejemplo . Supongo que usas algo de generación de código para escribir estas funciones de mapeo, pero eso parece decididamente poco parecido.

(Tenga en cuenta que no he mirado los Weblocks o los enlaces con mucha atención, puede que no esté entendiendo cómo se usan).

Entonces, la pregunta es, para las porciones de acceso a la base de datos (que creo que son bastante grandes) de la aplicación web u otro desarrollo que requiere una interfaz con una base de datos sql, parece que nos vemos obligados a seguir una de las siguientes rutas:

1. No use programación funcional
2. Acceda a los datos de una manera molesta y sin abstracción que implica escribir manualmente una gran cantidad de código SQL o similar a SQL ala Enlaces
3. Fuerce nuestro lenguaje funcional en un paradigma pseudo-OOP, eliminando así algo de la elegancia y la estabilidad de la verdadera programación funcional.

Claramente, ninguna de estas opciones parece ideal. ¿Ha encontrado una manera de sortear estos problemas? ¿Existe realmente un problema aquí?

Nota: Personalmente, estoy más familiarizado con LISP en el frente de FP, por lo que si desea dar algunos ejemplos y conocer varios idiomas de FP, es probable que lisp sea el idioma preferido de elección

PD: Para problemas específicos de otros aspectos del desarrollo web, vea esta pregunta .

En primer lugar, no diría que CLOS (Common Lisp Object System) es "pseudo-OO". Es de primera clase OO.

En segundo lugar, creo que debe usar el paradigma que se ajuste a sus necesidades.

No puede almacenar datos sin estado, mientras que una función es flujo de datos y realmente no necesita estado.

Si tiene varias necesidades entremezcladas, mezcle sus paradigmas. No se limite a usar solo la esquina inferior derecha de su caja de herramientas.

Llegando a esto desde la perspectiva de una persona de base de datos, encuentro que los desarrolladores front-end se esfuerzan demasiado por encontrar formas de hacer que las bases de datos se ajusten a su modelo en lugar de considerar las formas más efectivas de usar bases de datos que no están orientadas a objetos o funcionales, sino que son relacionales y usan teoría de conjuntos. He visto que esto generalmente da como resultado un código de bajo rendimiento. Y además crea código que es difícil de ajustar.

Cuando se considera el acceso a la base de datos, hay tres consideraciones principales: integridad de los datos (por qué todas las reglas comerciales deben aplicarse a nivel de la base de datos, no a través de la interfaz de usuario), rendimiento y seguridad. SQL está escrito para administrar las dos primeras consideraciones de manera más efectiva que cualquier lenguaje front-end. Porque está específicamente diseñado para hacer eso. La tarea de una base de datos es muy diferente de la tarea de una interfaz de usuario. ¿Es de extrañar que el tipo de código que sea más efectivo en la gestión de la tarea sea conceptualmente diferente?

Y las bases de datos contienen información crítica para la supervivencia de una empresa. No es de extrañar que las empresas no estén dispuestas a experimentar con nuevos métodos cuando su supervivencia está en juego. Heck muchas empresas no están dispuestas a actualizar incluso a nuevas versiones de su base de datos existente. Por lo tanto, existe un conservadurismo inherente en el diseño de bases de datos. Y es así deliberadamente.

No trataría de escribir T-SQL o usar conceptos de diseño de bases de datos para crear su interfaz de usuario, ¿por qué trataría de usar su lenguaje de interfaz y conceptos de diseño para acceder a mi base de datos? ¿Porque crees que SQL no es lo suficientemente elegante (o nuevo)? ¿O no te sientes cómodo con eso? El hecho de que algo no se ajuste al modelo con el que se siente más cómodo no significa que sea malo o incorrecto. Significa que es diferente y probablemente diferente por una razón legítima. Utiliza una herramienta diferente para una tarea diferente.

Debería consultar el documento "Fuera del pozo de alquitrán" de Ben Moseley y Peter Marks, disponible aquí: "Fuera del pozo de alquitrán" (6 de febrero de 2006)

Es un clásico moderno que detalla un paradigma / sistema de programación llamado Programación Funcional-Relacional. Si bien no se relaciona directamente con las bases de datos, analiza cómo aislar las interacciones con el mundo exterior (bases de datos, por ejemplo) del núcleo funcional de un sistema.

El documento también analiza cómo implementar un sistema en el que el estado interno de la aplicación se define y modifica utilizando un álgebra relacional, que obviamente está relacionada con las bases de datos relacionales.

Este documento no dará una respuesta exacta sobre cómo integrar bases de datos y programación funcional, pero le ayudará a diseñar un sistema para minimizar el problema.

1. Los lenguajes funcionales no tienen el objetivo de permanecer sin estado, tienen el objetivo de hacer explícita la gestión del estado. Por ejemplo, en Haskell, puede considerar la mónada estatal como el corazón del estado "normal" y la mónada IO una representación del estado que debe existir fuera del programa. Ambas mónadas le permiten (a) representar explícitamente acciones con estado y (b) construir acciones con estado componiéndolas usando herramientas transparentes referenciales.

2. Usted hace referencia a una serie de ORM, que, por su nombre, resumen las bases de datos como conjuntos de objetos. En verdad, ¡esto no es lo que representa la información en una base de datos relacional! Por su nombre, representa datos relacionales. SQL es un álgebra (lenguaje) para manejar relaciones en un conjunto de datos relacionales y en realidad es bastante "funcional". Menciono esto para considerar que (a) los ORM no son la única forma de mapear la información de la base de datos, (b) que SQL es en realidad un lenguaje bastante agradable para algunos diseños de bases de datos, y (c) que los lenguajes funcionales a menudo tienen álgebra relacional mapeos que exponen el poder de SQL de una manera idiomática (y en el caso de Haskell, con verificación de tipo).

Yo diría que la mayoría de los lisps son el lenguaje funcional de un hombre pobre. Es totalmente capaz de usarse de acuerdo con las prácticas funcionales modernas, pero dado que no las requiere, es menos probable que la comunidad las use. Esto conduce a una mezcla de métodos que pueden ser muy útiles, pero ciertamente oscurecen la forma en que las interfaces funcionales puras aún pueden usar bases de datos de manera significativa.

No creo que la naturaleza sin estado de los lenguajes fp sea un problema para conectarse a bases de datos. Lisp es un lenguaje de programación funcional no puro, por lo que no debería tener ningún problema con el estado. Y los lenguajes de programación funcionales puros como Haskell tienen formas de lidiar con las entradas y salidas que se pueden aplicar al uso de bases de datos.

A partir de su pregunta, parece que su principal problema radica en encontrar una buena manera de abstraer los datos basados ​​en registros que obtiene de su base de datos en algo que es lisp-y (¿lisp-ish?) Sin tener que escribir mucho SQL código. Esto parece más un problema con las herramientas / bibliotecas que un problema con el paradigma del lenguaje. Si quieres hacer FP puro, tal vez lisp no sea el lenguaje adecuado para ti. El lisp común parece más sobre integrar buenas ideas de oo, fp y otros paradigmas que sobre fp puro. Tal vez deberías estar usando Erlang o Haskell si quieres ir a la ruta FP pura.

Creo que las ideas de 'pseudo-oo' en lisp también tienen su mérito. Es posible que desee probarlos. Si no se ajustan a la forma en que desea trabajar con sus datos, puede intentar crear una capa sobre Weblocks que le permita trabajar con sus datos de la manera que desee. Esto podría ser más fácil que escribir todo usted mismo.

Descargo de responsabilidad: no soy un experto de Lisp. Estoy principalmente interesado en los lenguajes de programación y he estado jugando con Lisp / CLOS, Scheme, Erlang, Python y un poco de Ruby. En la vida diaria de programación todavía me veo obligado a usar C #.

Si su base de datos no destruye la información, entonces puede trabajar con ella de una manera funcional consistente con los valores de programación "puramente funcionales" trabajando en funciones de la base de datos completa como un valor.

Si en el momento T la base de datos dice que "a Bob le gusta Suzie", y tuviste una función que le gustó y aceptó una base de datos y un me gusta, entonces mientras puedas recuperar la base de datos en el momento T, tienes un programa funcional puro que involucra una base de datos . p.ej

# Start: Time T
likes(db, "Bob")
=> "Suzie"
# Change who bob likes
...
likes(db "Bob")
=> "Alice"
# Recover the database from T
db = getDb(T)
likes(db, "Bob")
=> "Suzie"

Para hacer esto, nunca puede tirar la información que podría usar (lo que en la práctica significa que no puede tirar la información), por lo que sus necesidades de almacenamiento aumentarán monotónicamente. Pero puede comenzar a trabajar con su base de datos como una serie lineal de valores discretos, donde los valores posteriores están relacionados con los anteriores a través de transacciones.

Esta es la idea principal detrás de Datomic , por ejemplo.

De ningún modo. Hay un género de bases de datos conocido como 'Bases de datos funcionales', de las cuales Mnesia es quizás el ejemplo más accesible. El principio básico es que la programación funcional es declarativa, por lo que se puede optimizar. Puede implementar una unión usando List Comprehensions en colecciones persistentes y el optimizador de consultas puede determinar automáticamente cómo implementar el acceso al disco.

Mnesia está escrito en Erlang y hay al menos un marco web ( Erlyweb ) disponible para esa plataforma. Erlang es intrínsecamente paralelo con un modelo de subprocesamiento de nada compartido, por lo que, en cierto modo, se presta a arquitecturas escalables.

Una base de datos es la manera perfecta de realizar un seguimiento del estado en una API sin estado. Si se suscribe a REST, su objetivo es escribir código sin estado que interactúe con un almacén de datos (o algún otro servidor) que realice un seguimiento de la información de estado de manera transparente para que su cliente no tenga que hacerlo.

La idea de un asignador relacional de objetos, donde importa un registro de base de datos como un objeto y luego lo modifica, es tan aplicable y útil para la programación funcional como para la programación orientada a objetos. La única advertencia es que la programación funcional no modifica el objeto en su lugar, pero la API de la base de datos puede permitirle modificar el registro en su lugar. El flujo de control de su cliente se vería así:

• Importe el registro como un objeto (la API de la base de datos puede bloquear el registro en este punto),
• Lea el objeto y la rama según su contenido como desee,
• Empaquete un nuevo objeto con sus modificaciones deseadas,
• Pase el nuevo objeto a la llamada API apropiada que actualiza el registro en la base de datos.

La base de datos actualizará el registro con sus cambios. La programación funcional pura podría no permitir la reasignación de variables dentro del alcance de su programa , pero la API de su base de datos aún puede permitir actualizaciones en el lugar.

Me siento más cómodo con Haskell. El marco web más destacado de Haskell (comparable a Rails y Django) se llama Yesod. Parece tener un ORM bastante genial, seguro para los tipos y de backend múltiple. Echa un vistazo al capítulo Persistencia en su libro.

Las bases de datos y la programación funcional pueden fusionarse.

por ejemplo:

Clojure es un lenguaje de programación funcional basado en la teoría de bases de datos relacionales.

               Clojure -> DBMS, Super Foxpro
                   STM -> Transaction，MVCC
Persistent Collections -> db, table, col
              hash-map -> indexed data
                 Watch -> trigger, log
                  Spec -> constraint
              Core API -> SQL, Built-in function
              function -> Stored Procedure
             Meta Data -> System Table

Nota: En la última especificación2, la especificación se parece más a RMDB. ver: spec-alpha2 wiki: Schema-and-select

Yo defiendo: construir un modelo de datos relacionales sobre el mapa hash para lograr una combinación de ventajas NoSQL y RMDB. Esta es en realidad una implementación inversa de posgtresql.

Mecanografía de pato: si parece un pato y grazna como un pato, debe ser un pato.

Si el modelo de datos de clojure como un RMDB, las instalaciones de clojure como un RMDB y la manipulación de datos de clojure como un RMDB, clojure debe ser un RMDB.

Clojure es un lenguaje de programación funcional basado en la teoría de bases de datos relacionales

Todo es RMDB

Implemente un modelo de datos relacionales y una programación basada en hash-map (NoSQL)