对于大多数接受 SP 培训的开发人员来说，在 Linq 和存储过程/函数之间没有选择。这可能是真的。
然而，现在有一个路口。在我花太多时间研究 F# 的语法之前，我想了解更多关于 F# 的力量(和相反)的信息。
F# 在这个主题上的表现如何(相对于 SP)？
F# 必须以某种方式与数据库通信。通过 Linq2Sql/Entity-app-layer 或直接通过 AnyDbConnection。那里没有什么新鲜事。但是 F# 具有并行性的强大功能，并且在他们的工作中开销更少 (Functional Programming with C#/F#)。 F# 还具有作为数据和机器层的效率。非常类似于 C# 作为人机之间层的力量。
- 我真的会让数据库服务器处理重复节点的请求，还是只将纯数据提取到 F# 并在那里处理？作为从 C# 的对象方法调用封装得很好、很流畅？
- 存储过程是否仍然是扫描 5000 万条记录以查找孤儿或匹配 0.5% 结果的标准的最佳选择？
- SP 或函数是否仍然最适合查找下一个父节点这样的简单任务？
- SP 是否仍然最好收集一百万条数据记录并返回计算的总和和/或周期？
完全基于单一职责原则构建的单个 f# dll 库是否比连接在 sql server 中的存储过程更有用？当然有利也有弊。但它们是什么？
最佳答案
存储过程并没有神奇的超快。通常，它们实际上相当慢。
许多人会对这个答案投反对票，提供轶事证据表明存储过程曾经使应用程序总体上更快。但是，我实际看到的所有这些示例的代码都表明，他们完全重新考虑了一些糟糕的 SQL 以将其打包为 SP。我认为将错误的 SQL 重新打包到过程中的原则比 SP 本身更有帮助。
如果没有衡量基准，您的大部分观点都无法评估。
我建议您执行以下操作。
用 F# 编写。
测量它。
如果它对于您的生产应用程序来说太慢，请尝试一些存储过程以查看它是否更快。如果它对于您的生产应用程序来说足够快，那么您就有了答案，F# 适合您。为您的应用程序。为了你的数据。为您的架构。
没有“一般”的答案。尽管我对某些特定类型查询的基准测试表明 SP 引擎与 Java 相比相当慢。 F# 也可能比 SP 引擎更快。
重要的是要确保数据库——如果它是“纯”数据——已经过优化，以便像“扫描 5000 万条记录以查找孤儿或匹配 0 的条件”这样的查询，结果的5%？”将尽快检索行。这通常涉及调整缓冲区和数组大小以及数据库到 F# 连接的其他元素。这通常意味着您需要更直接的连接，以便您可以调整尺寸。
关于sql - 存储过程 VS。 F#，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5065046/