数据库和函数式编程有何不同？
我一直是一个Web开发人员，并且最近开始学习一些函数式编程。 和其他人一样，我将这些概念中的许多应用于我的专业工作方面遇到了一些重大困难。 对我来说，主要原因是我看到FP之间的无状态目标之间的矛盾似乎与我所做的大多数Web开发工作都与数据库密切相关，这些数据库非常以数据为中心。
有一件事使我成为OOP方面更有成效的开发人员，就是发现了MyGeneration d00dads for .NET，Class :: DBI for perl，ActiveRecord for ruby等对象关系映射器。这使我可以远离从整天写入插入和选择语句开始，并专注于将数据作为对象轻松处理。 当然，我仍然可以在需要它们的权力时编写SQL查询，但否则它会在幕后很好地抽象出来。
现在，转向功能性编程，像Links这样的许多FP Web框架似乎需要编写大量的样板SQL代码，如本例中所示。 网络锁看起来好一点，但它似乎使用了一种OOP模型来处理数据，并且仍需要为数据库中的每个表手动编写代码，如本例中所示。 我想你使用一些代码生成来编写这些映射函数，但是这看起来显然是不喜欢的。
（请注意，我没有仔细查看Weblocks或Links，我可能会误解它们的使用方式）。
所以问题是，对于Web应用程序的数据库访问部分（我认为这些部分相当大），或者需要与sql数据库接口的其他开发，我们似乎被迫停用以下路径之一：
显然，这些选择都不是理想的。 是否找到了解决这些问题的方法？ 这里真的有一个问题吗？
注意：我个人最熟悉FP前端的LISP，所以如果你想给出任何例子并且知道多种FP语言，lisp可能是首选的语言选择
PS：有关Web开发其他方面的问题，请参阅此问题。
首先，我不会说CLOS（Common Lisp Object System）是“伪OO”。 这是一流的OO。
其次，我相信你应该使用适合你需求的范例。
你不能无状态地存储数据，而一个函数是数据流，并不需要状态。
如果你有几种混合的需求，混合你的范例。 不要只限于使用工具箱的右下角。
从数据库人员的角度来看，我发现前端开发人员试图想方设法使数据库适合他们的模型，而不是考虑使用数据库的最有效方法，这些方法不是面向对象或功能性的，而是关系性的，并且使用设置理论。 我看到这通常会导致代码执行不良。 此外，它会创建难以调整性能的代码。
考虑数据库访问时，主要考虑三个方面 - 数据完整性（为什么所有业务规则都应在数据库级别执行，而不是通过用户界面执行），性能和安全性。 编写SQL是为了比前端语言更有效地管理前两种注意事项。 因为它是专门设计来做到这一点的。 数据库的任务远远不同于用户界面的任务。 难怪在管理任务中最有效的代码类型在概念上是不同的？
数据库拥有对公司生存至关重要的信息。 难怪企业在生存受到威胁时不愿尝试新方法。 很多企业都不愿意升级到现有数据库的新版本。 所以在数据库设计中存在内在的保守性。 这是故意的。
我不会尝试编写T-SQL或使用数据库设计概念来创建用户界面，为什么要尝试使用界面语言和设计概念来访问我的数据库？ 因为你认为SQL不够花哨（或新）不够？ 或者你觉得不舒服？ 仅仅因为某些东西不适合你最喜欢的模型，并不意味着它是不好的或者错误的。 这意味着它是不同的，并可能因合法原因而不同。 您为不同的任务使用不同的工具。
你应该看Ben Moseley和Peter Marks的论文“走出焦油坑”，可以在这里找到：“走出焦油坑”（2006年2月6日）
这是一个现代的经典，它详细介绍了一种称为功能关系编程的编程范例/系统。 虽然与数据库没有直接关系，但它讨论了如何从系统的功能核心中隔离与外部世界的交互（例如数据库）。
本文还讨论了如何使用关系代数来定义和修改应用程序的内部状态，这显然与关系数据库有关。
本文不会给出如何集成数据库和函数式编程的确切答案，但它可以帮助您设计一个系统来最小化问题。
链接地址: http://www.djcxy.com/p/79331.html