数据库和函数式编程是否不一致？

Question

我已经做了一段时间的web开发人员，最近开始学习一些函数式编程。和其他人一样，我在将这些概念应用于我的专业工作时遇到了一些重大的困难。对我来说，最主要的原因是我认为FP保持无状态的目标之间的冲突似乎与我所做的大多数web开发工作都与数据库紧密相连这一事实是不一致的，因为数据库是非常以数据为中心的。

在面向对象方面，有一件事使我成为了更有效率的开发人员，那就是发现了对象关系映射器，如MyGeneration d00dads for .Net，Class::DBI for perl，ActiveRecord for ruby等等，这使我可以一整天不编写insert和select语句，并专注于轻松地将数据作为对象处理。当然，当需要SQL查询时，我仍然可以编写它们，但否则它会在幕后很好地被抽象。

现在，转到函数式编程，似乎许多FP web框架(如链接)都需要编写大量的样板sql代码，就像在这个例子中那样。Weblocks似乎更好一些，但它似乎使用了一种OOP模型来处理数据，并且仍然需要为数据库中的每个表手工编写代码，就像在这个例子中那样。我想您应该使用一些代码生成来编写这些映射函数，但这显然是不lisp式的。

(请注意，我没有非常仔细地查看Weblocks或链接，我可能只是误解了它们的使用方式)。

所以问题是，对于web应用程序的数据库访问部分(我认为这些部分相当大)，或者其他需要与sql数据库接口的开发，我们似乎不得不走下以下几条路径之一：

1. 不要使用函数式编程
2. 以一种烦人的、非抽象的方式访问数据，这涉及手动编写大量的SQL或类似SQL的代码ala链接。
3. 强制我们的函数式语言进入一个伪OOP范型，从而消除一些优雅和稳定的真正的函数式编程。

显然，这些选择似乎都不理想。找到解决这些问题的方法了吗？这里真的有什么问题吗？

注意:我个人对FP方面的LISP最熟悉，所以如果您想给出任何例子并了解多种FP语言，lisp可能是首选语言。

PS:有关web开发的其他方面的特定问题，请参阅这个问题。

Answer 1

从数据库人的角度来看，我发现前端开发人员过于努力地寻找使数据库符合其模型的方法，而不是考虑使用数据库的最有效方法，这些方法不是面向对象的，也不是函数的，而是关系型的，使用集合论的。我已经看到这通常会导致性能较差的代码。此外，它还创建了难以优化性能的代码。

在考虑数据库访问时，有三个主要考虑因素:数据完整性(为什么所有业务规则都应该在数据库级别强制执行，而不是通过用户界面)、性能和安全性。编写SQL是为了比任何前端语言更有效地管理前两个注意事项。因为它是专门设计的。数据库的任务与用户界面的任务大不相同。在管理任务时最有效的代码类型在概念上不同，这有什么奇怪的吗？

数据库保存着对公司生存至关重要的信息。当他们的生存受到威胁时，企业不愿意尝试新的方法，这是任何奇怪的事情。令人见鬼的是，许多企业甚至不愿升级到现有数据库的新版本。因此，数据库设计存在固有的保守性。而且这是故意的。

我不会尝试编写to或使用数据库设计概念来创建用户界面，您为什么要尝试使用您的接口语言和设计概念来访问我的数据库呢？因为您认为SQL不够花哨(或新的)吗？还是你觉得不舒服？仅仅因为某些东西不适合你觉得最舒服的模型，并不意味着它是坏的或错误的。这意味着它是不同的，而且可能出于一个正当的原因而有所不同。您使用不同的工具来执行不同的任务。

Answer 2

你应该看看本·莫斯利和彼得·马克斯的“走出焦油坑”的论文，在这里可以找到：“走出焦油坑”(2006年2月6日)。

这是一部现代经典，它详细描述了一个叫做功能-关系编程的编程范式/系统。虽然与数据库没有直接关系，但它讨论了如何将与外部世界(例如数据库)的交互与系统的功能核心隔离开来。

本文还讨论了如何使用关系代数来定义和修改应用程序的内部状态，这显然与关系数据库有关。

本文不会给出如何集成数据库和函数式编程的确切答案，但它将帮助您设计一个系统，使问题最小化。

Answer 3

1. 函数式语言没有保持无状态的目标，它们的目标是使状态管理显式化。例如，在Haskell中，您可以将State看作“正常”状态的核心，而IO monad则是程序之外必须存在的状态的表示形式。这两个单体允许您(a)显式表示有状态操作，(b)通过使用引用透明工具组合有状态操作来构建有状态操作。
2. 您引用了许多ORM，根据它们的名称，将数据库抽象为一组对象。事实上，这不是关系数据库中的信息所代表的！根据它的名称，它表示关系数据。SQL是一种代数(语言)，用于处理关系数据集上的关系，实际上它本身是相当“功能”的。我提出这一点是为了考虑：(a) ORMs不是映射数据库信息的唯一方法，(b)对于某些数据库设计来说，SQL实际上是一种相当不错的语言，(c)函数式语言通常具有关系代数映射，它们以惯用的方式(在Haskell的情况下，类型化)公开SQL的功能。

我想说的是，大多数的语言都是穷人的功能性语言。根据现代功能实践，它完全能够被使用，但是由于它不需要它们，所以社区不太可能使用它们。这导致了各种方法的混合，这些方法可能非常有用，但当然也掩盖了纯功能接口如何仍然有意义地使用数据库。