sql - programacion - ¿Las bases de datos y la programación funcional están en desacuerdo?
programacion funcional ventajas y desventajas (9)
He sido desarrollador web desde hace un tiempo y recientemente comencé a aprender algo de programación funcional. Al igual que otros, he tenido algunos problemas importantes para aplicar muchos de estos conceptos a mi trabajo profesional. Para mí, la razón principal para esto es que veo un conflicto entre el objetivo de FP de quedarse sin estado parece bastante en desacuerdo con el hecho de que la mayoría del trabajo de desarrollo web que he hecho se ha relacionado fuertemente con 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 OOP de las cosas 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 insertar y seleccionar declaraciones todo el día, y centrarse 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 abstraía muy bien entre bastidores.
Ahora, volviendo a la programación funcional, parece que con muchos de los marcos web de FP, como los enlaces, se requiere escribir un montón de código sql estándar, como en este ejemplo . Weblocks parece un poco mejor, pero parece utilizar un tipo de modelo de OOP para trabajar con datos, y aún requiere que se escriba manualmente el código 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 desacostumbrado.
(Tenga en cuenta que no he analizado Weblocks o Links muy de cerca, es posible que esté malinterpretando 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 requiera una interfaz con una base de datos sql, parece que nos vemos forzados a seguir una de las siguientes rutas:
- No use programación funcional
- Acceda a los datos de una manera molesta, no abstracta, que implica la escritura manual de una gran cantidad de código SQL o SQL ala Enlaces
- Forzar nuestro lenguaje funcional en un paradigma pseudo-OOP, eliminando así parte de la elegancia y la estabilidad de la verdadera programación funcional.
Claramente, ninguna de estas opciones parece ideal. Ha encontrado una forma de eludir estos problemas? ¿Existe realmente incluso un problema aquí?
Nota: Personalmente, estoy más familiarizado con LISP en el frente de FP, así que si quiere dar ejemplos y conocer varios lenguajes de FP, es probable que el lenguaje de preferencia sea el lisp.
PD: para problemas específicos de otros aspectos del desarrollo web, vea esta pregunta .
Los lenguajes funcionales no tienen el objetivo de permanecer sin estado, tienen el objetivo de hacer explícita la administración del estado. Por ejemplo, en Haskell, puede considerar la mónada de estado como el corazón del estado "normal" y la mónada IO como 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) crear acciones con estado al componerlas utilizando herramientas transparentes de referencia.
Hace referencia a un número de ORM, que, por su nombre, abstraen las bases de datos como conjuntos de objetos. ¡Verdaderamente, 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". Hago referencia a 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 realmente un lenguaje 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, tipocheck).
Diría que la mayoría de los ceceos son el lenguaje funcional de un pobre hombre. Es totalmente capaz de ser utilizado de acuerdo con las prácticas funcionales modernas, pero como no lo requiere, es menos probable que la comunidad lo use. Esto lleva a una mezcla de métodos que pueden ser muy útiles, pero ciertamente oscurece cómo las interfaces funcionales puras aún pueden usar bases de datos de manera significativa.
Al ver esto desde la perspectiva de una persona de base de datos, encuentro que los desarrolladores intentan mucho para 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 relacionales y teoría de conjuntos. He visto esto generalmente como resultado un código de bajo rendimiento. Y además crea código que es difícil de ejecutar melodía.
Al considerar 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 de 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 es más eficaz en la gestión de la tarea es 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. Diablos, muchas empresas no están dispuestas a siquiera actualizar a nuevas versiones de su base de datos existente. Entonces hay un conservadurismo inherente en el diseño de la base de datos. Y es deliberadamente de esa manera.
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 piensas 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 sienta 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.
Antes que nada, no diría que CLOS (Common Lisp Object System) es "pseudo-OO". Es de primera clase OO.
Segundo, creo que debes usar el paradigma que se ajuste a tus necesidades.
No puede almacenar datos de manera anónima, 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 solo a usar la esquina inferior derecha de su caja de herramientas.
De ningún modo. Hay un género de bases de datos conocidas 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 puede optimizarse. Puede implementar una unión utilizando Comprensión de listas en colecciones persistentes y el optimizador de consultas puede resolver automágicamente 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 ciertos aspectos se presta a arquitecturas escalables.
Debería ver el artículo "Fuera del foso de alquitrán" de Ben Moseley y Peter Marks, disponible aquí: "Fuera del foso 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, se analiza cómo aislar las interacciones con el mundo exterior (bases de datos, por ejemplo) desde el núcleo funcional de un sistema.
El documento también discute cómo implementar un sistema donde el estado interno de la aplicación se define y modifica usando un álgebra relacional, que obviamente está relacionada con bases de datos relacionales.
Este documento no brindará 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.
Estoy más cómodo con Haskell. El marco web Haskell más prominente (comparable a Rails y Django) se llama Yesod. Parece tener un ORM bastante bueno, tipo seguro y multi-backend. Eche un vistazo al capítulo de Persistance en su libro.
No creo que la naturaleza apátrida de los lenguajes fp sea un problema para conectarse a las 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 manejar las entradas y salidas que se pueden aplicar al uso de bases de datos.
A partir de su pregunta, parece que su principal problema reside 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 es el idioma correcto para ti. El ceceo común parece más sobre la integración de buenas ideas de oo, fp y otros paradigmas que sobre el fp puro. Tal vez deberías estar usando Erlang o Haskell si quieres ir a la ruta pura de FP.
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 en Lisp. Estoy interesado principalmente en lenguajes de programación y he estado jugando con Lisp / CLOS, Scheme, Erlang, Python y un poco de Ruby. En la vida de programación diaria, todavía estoy obligado a usar C #.
Si su base de datos no destruye la información, entonces puede trabajar con ella de una manera funcional y coherente con los valores de programación "puramente funcionales" al trabajar en funciones de toda la base de datos como un valor.
Si en el momento T la base de datos indica que "a Bob le gusta Suzie", y usted tiene una función que acepta una base de datos y una aplicación, siempre que pueda recuperar la base de datos en el momento T tiene 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, no puedes descartar la información que puedas usar (lo que en términos prácticos significa que no puedes descartar la información), por lo que tus necesidades de almacenamiento aumentarán monótonamente. Pero puede comenzar a trabajar con su base de datos como una serie lineal de valores discretos, donde los valores posteriores se relacionan con los anteriores a través de las transacciones.
Esta es la idea principal detrás de Datomic , por ejemplo.
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 un código sin estado que interactúe con un almacén de datos (o algún otro servidor) que haga un seguimiento de la información de estado de manera transparente para que su cliente no tenga que hacerlo.
La idea de un Object Relational Mapper, donde importa un registro de base de datos como un objeto y luego lo modifica, es tan aplicable y útil tanto 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 base de datos puede bloquear el registro en este punto),
- Lea el objeto y la rama en función de su contenido como lo desee,
- Empaquete un nuevo objeto con sus modificaciones deseadas,
- Pase el nuevo objeto a la llamada API correspondiente que actualice 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 su API de base de datos aún puede permitir actualizaciones in situ.