sql - 数据库和函数式编程矛盾吗？

Question

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

让我在 OOP 方面成为更有效率的开发人员的一件事是发现了对象关系映射器，例如用于 .Net 的 MyGeneration d00dads、用于 perl 的 Class::DBI、用于 ruby​​ 的 ActiveRecord 等。这让我远离整天编写插入和选择语句，并专注于将数据作为对象轻松处理。当然，我仍然可以在需要 SQL 查询时编写 SQL 查询，但除此之外它在幕后被很好地抽象了。

现在，转向函数式编程，许多 FP Web 框架(如 Links)似乎需要编写大量样板 sql 代码，如 this example . Weblocks 似乎好一点，但它似乎使用某种 OOP 模型来处理数据，并且仍然需要为数据库中的每个表手动编写代码，如 this example 中所示。 .我想您使用了一些代码生成来编写这些映射函数，但这看起来显然不像 lisp。

(请注意，我没有仔细查看 Webblocks 或 Links，我可能只是误解了它们的使用方式)。

所以问题是，对于 Web 应用程序的数据库访问部分(我认为它们相当大)，或其他需要与 sql 数据库接口(interface)的开发，我们似乎被迫走以下路径之一:

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

显然，这些选项似乎都不理想。是否找到了规避这些问题的方法？这里真的有问题吗？

注意:我个人最熟悉 FP 前端的 LISP，因此如果您想举任何例子并了解多种 FP 语言，lisp 可能是首选语言

PS:有关 Web 开发其他方面的特定问题，请参阅 this question .

Answer 1

从数据库人员的角度来看，我发现前端开发人员过于努力地寻找使数据库适合他们模型的方法，而不是考虑使用数据库的最有效方法，这些方法不是面向对象或功能性的，而是关系和使用集合论。我已经看到这通常会导致代码性能不佳。此外，它会创建难以进行性能调整的代码。

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

数据库保存着对公司生存至关重要的信息。难怪企业在生存受到威胁时不愿意尝试新方法。哎呀，许多企业甚至不愿意升级到现有数据库的新版本。因此，数据库设计中存在固有的保守主义。这是故意的。

我不会尝试编写 T-SQL 或使用数据库设计概念来创建您的用户界面，为什么您会尝试使用您的界面语言和设计概念来访问我的数据库？因为您认为 SQL 不够花哨(或新颖)？或者你觉得不舒服？仅仅因为某些东西不适合您觉得最舒服的模型，并不意味着它是坏的或错误的。这意味着它是不同的，并且可能出于正当理由而不同。您使用不同的工具来完成不同的任务。