仍然需要编写SQL吗？

拥有适用于大多数现代语言的众多ORM工具，是否仍存在用支持它们的语言/环境在程序中编写和执行SQL的用例？如果可以，为什么？

为了清楚起见：我不是在问程序员是否需要了解SQL，或者我是否应该在桌面上安装SQL工具。我在问一个具体的原因，为什么我可能会在代码（或配置或其他内容）中使用它而不是ORM。

• 与编写过程代码相比，编写SQL查询数据更舒适。
• 您的ORM看上去很漂亮，但在某些关键区域却会产生极其缓慢的SQL。
• 您需要利用RDBMS公开的功能，而该功能不是/无法通过ORM提供的。
• 每次键入时SELECT * FROM...，上帝都会杀死一只小猫。而且你讨厌小猫。
• 您使用的不是ORM，OOP或现代语言。

编写复杂的SQL

ORM非常适合基本事物。但是，对于复杂的情况，您将必须编写SQL。

简而言之，最肯定的是需要SQL，并且它将一直如此。

• 观看次数
• 扳机
• 约束条件
• 包（SSIS，DTS等）
• 任何时候您需要精确地控制执行流程

ORM不能帮助您构建，调整或自动化数据库。完成所有这些操作后，它只是为您提供了一种与数据库交互的替代方法。

当然：

• 通常，ORM封装很多，但最后您应该知道幕后发生的事情。这对于性能和可伸缩性至关重要。虽然在应用程序内部我编写的SQL并不多，但是我大致知道SQL或DDL的外观。
• Direct SQL通常很适合编写只读查询。用ORM查询语言来表达它要容易得多，您还可以限制结果集（例如，“从......中选择ID”）。
• ORM不应完全使您远离SQL。我直接在DB客户端（例如mysql客户端）上使用SQL进行临时查询。它为您提供了非常好的统一界面和分组功能。

由于常见的关系数据库实现与OO语言功能之间存在阻抗不匹配，因此存在ORM。它们只是一座桥梁，但大多数人将SQL像冰箱中的林堡奶酪一样对待。

如果您有理由说您将始终使用ORM或其他抽象的数据访问层，而不是将SQL /存储过程/视图视为一流的接口，那么您最好不接触SQL。

实际上，我从未见过一个纯ORM项目，该项目至少不需要SQL即可查询数据库以进行最终验证。

ORM是程序员工具箱中的工具。他们有自己的问题。一些例子是：

• 无法控制SQL
• 遭受n + 1问题

如果您知道自己在做什么，则可以有效地使用ORM替换许多CRUD类型代码。但是，它们在复杂的事情上没有那么有效，它们很难进行性能调整（您确实知道性能是数据库设计的关键部分之一，而不是模拟对象），并且在不这样做的人的手中它们是彻头彻尾的恐怖和危险自己不懂SQL。

我还想指出，使用ORM很难有效地完成复杂的报告。而且，如果您没有从简单的知识中学习简单的SQL，您将如何达到编写复杂的SQL进行报告的地步呢？我从来没有在没有报告需求且通常很复杂的应用程序中工作过。

在大多数情况下，ORM对BI或ETL流程也无用。它们对于数据库管理员查询或在审计表中查找信息以及撤消一组特定的数据库更改也没有用。使用SQL仍然可以有效地完成许多工作。查询数据库的应用程序只是企业环境中查询数据库的一小部分。

我也看到许多有关如何使用张贴者已经知道如何在SQL中执行的ORM进行操作的问题。学习新事物很高兴，但是当它们花费额外的时间和精力却又没有比原始方法真正的收获（通常是性能的真正损失）时，为什么要使用它们而不是现在的“时尚”。

有时，客户只是希望快速轻松地查询以返回报表，导出，数据转储等数据，并希望等待整个程序的开发。

而且，一个优秀的SQL程序员总是可以比我使用的任何ORM编写更快，更高效的SQL。另外，我发现很多人只是将ORM指向存储过程-真的忽略了ORM的好处，因为ORM对于复杂的过程而言不是很好。

而且，当使用具有非常丰富而强大的过程语言的Oracle之类的数据库时，无需执行“程序”就可以完成很多工作。正确使用Oracle上的PL / SQL是非常快捷和高效的。

如果您想自己使用数据库，可以。我尝试使用的大多数ORM都不够用或没有覆盖我的数据库。此外，您将如何解决或编写未涵盖的自定义查询？

编写触发器和存储过程仍然需要它。当前，存储过程可能已不受欢迎，但在某些情况下它们仍然非常有用。对于某些特别繁琐的多表联接，可能还需要SQL。

是的，您可以避免编写SQL。但是您最终将改为编写HQL（或Linq或DQL ...）！

认真地说，我是ORM的忠实拥护者，而且我确实认为大多数时候都可以避免使用纯SQL。但是我们必须记住，ORM只是一个大抽象，所有大抽象都在泄漏 ...

（但是关于N + 1问题：这是与延迟加载有关的，并且大多数ORM工具都有某种请求紧急加载的方式，从而避免了该特定问题。）

ORM只会带您到某个地方。但是在某些情况下，您必须执行一个非常复杂的查询，包括复杂的联接，子查询，联合，减号，分析函数等。那就是您需要SQL的时候。但是，当您将所有简单查询留给ORM时，应该如何编写复杂查询？

即使您不需要在代码中编写它，也可以在对数据库服务器进行终端访问时使用它。

同样，使编程成为挑战的大多数事情都是在生命所设置的限制内进行的-通常我们使用的是旧代码或旧版本的数据库，并且没有机会为我们使用的任何语言安装最新的ORM库一起工作。在这种情况下，您将需要任何工具。

在其余时间中，您可能不需要SQL来处理CRUD，但是除了简单的SELECT，INSERT，UPDATE和基本JOIN查询外，SQL还有很多其他功能。您可以使用它来做非常聪明的事情，尽管您可能不经常使用它们，但是了解它们的用途很有用。

我认为我们会越来越多地进入后SQL世界，但是-大多数云服务使用非SQL表存储，并且对于简单的CRUD类型工作，不需要SQL的全部功能。但这并不意味着理解它没有任何价值。

而且，当然，如果当前的系统还不够完善，那么必须有人知道才能编写出更好的ORM系统。如果他们知道SQL，它将对他们有帮助...

对于构建大型Web应用程序来说，这完全没有必要，并且可能使事情变得比原本需要的事情更加繁重且浪费时间。这样做的原因是，任何大型应用程序都应利用内存持久层（在RAM中），该持久层应该是数据库中经常使用的内存缓存部分。

如果您必须使用没有足够内存的移动设备来做事，则正在编程的应用程序在移动设备，平板电脑等设备上作为“客户端”或独立应用程序运行，而不是使用SQL之类的事情仍然很常见，并且很重要，因为设备上的内存太小，以致您无法在内存中缓存很多内容。

我编写的SQL的复杂性和数量不足以合理地挂钩ORM框架。

（如果可能，我可能每月写一次SQL）

我遇到过许多与DBA接触的大型公司，他们积极地担心使用ORM工具的开发人员。

他们是涉及调优和性能的DBA。

是的，可以对ORM工具进行类似的管理，但是我已经看到它们仅接受存储过程（Sql Server）的地方，并且会询问您在其中执行的操作。

而且，ORM工具可能会被严重滥用，并产生与自己编写Sql一样差的Sql。

一大优势-DDL和数据库迁移。有时，您需要手工缝制这些东西以更新事物而不破坏现有数据。