如果我很了解ORM框架，SQL是否重要？[关闭]

我在SQL方面没有任何认真的经验，我甚至讨厌编写SQL而不是LINQ。我对ORM感到很满意。

从雇主和部门的角度来看，了解SQL是否重要？我必须掌握吗？与ORM框架相比，偏爱纯SQL的公司在编程世界中是否是“恐龙”？

这对很多程序员来说很难解释，因为如果您只了解基本的 SQL，那么与ORM相比，它实际上并没有给您带来太多优势。但是，更高级的SQL概念是仅能正常工作的应用程序与高质量（特别是快速和可靠）的应用程序之间区别的关键部分。

我假设别人设计的数据库给你，因为这是不知道任何SQL仅仅是踏破铁鞋。但是，即使您只是针对它们而开发，这里也只是ORM仍会做得不好或根本不做的所有事情的部分列表：

• 递归和/或层次结构查询
• 可选参数（尤其是将它们转换为范围谓词）
• 用户定义的数据类型
• 特定于平台的类型（SQL层次结构和TVP，Oracle数组和嵌套表等）
• 批量插入/更新/更新/删除
• 索引提示
• 锁提示（尤其是更新锁和脏读）
• 错误处理
• 外部联接-它们的结果集很难映射到OOP模型，许多ORM都有自己的查询语言，但这类似于了解SQL本身。
• 通过存储过程和UDF进行模块化，尤其是内联UDF和CROSS APPLY查询
• 使用OUTPUT / RETURNING将数据分段到多个表中
• 高效的分页查询
• 基于窗口函数的查询（行数，等级，分区）

清单还在不断增加-其中许多都是DBA初学者从未做过的事情，而且新手开发人员甚至从未听说过-但是它们在大型应用程序中非常重要。

ORM确实非常擅长加速真正无聊的 SQL代码-也就是说，所有重复的CRUD和映射以及其他管道代码，因此使用它们绝对没有什么可耻的，并且不要听别人说它们是邪恶的。但是您绝对仍然需要学习，是的，甚至是精通 SQL，并且在ORM不能发挥其作用时，准备好进入原始的DB命令/查询。

绝对！SQL仍然是数据库的通用语言，尽管您可能对ORM做了很多工作，但您必须了解SQL才能理解ORM做出的决策及其生成的SQL。另外，自定义sql和存储过程还有很多事情要做。对不起，没有免费的午餐。

是的，您仍然需要了解SQL。ORM是一个非常泄漏的抽象，并且不提供对SQL的全部功能的访问。对于玩具应用程序，您可能会了解有限的SQL知识。对于企业应用程序，您将必须了解数据库才能从ORM获得良好的性能。另外，与应用程序语言相比，使用SQL更容易完成许多任务。我已经看到Java程序员花几天时间编写代码来完成本可以在一小时内用SQL编写的代码。SQL知识对于编写使用关系数据库的应用程序的任何人都非常有价值。

SQL技能是当今IT必不可少的技能。LINQ是Microsoft Only技术。SQL的用法不仅限于Web和客户端/服务器应用程序开发。如果您对SQL不满意，则无法对数据库建模并执行ETL。您可能不需要掌握ORACLE和SQL Server的Data Warehous产品中使用的SQL方言，但是您应该了解标准SQL。SQL基础很简单，有很多材料可以帮助您入门。

如果要与SQL数据库进行交互，则必须了解ORM生成的SQL。您必须了解SQL数据库中固有的概念，并且必须了解ORM无法为您做些什么。ORM使生活更轻松（是的，我认为在许多情况下，没有人工作就可以使您成为恐龙），但它们是工具（用于抽象您所知道的事物），而不是拐杖（用于防止您学习）。

如果您拒绝学习SQL，那么无论有没有ORM，您都不会接触SQL数据库，您应该找到另一种类型的工作。

我会承认我是顽固的ORM拥护者，多年来一直在宣扬ORM的好处，并且对于ORM为什么胜过SQL仍有很多话要说。

但...

我必须承认，在现实世界中完全需要SQL，并且每个开发人员都应该对SQL有很好的理解。

在几乎所有情况下，SQL proc都比ORM更快。即使您在大多数情况下也可以乐观地看待ORM输出，也可以使它紧跟SQL proc之后。

有时，您需要一些繁重的SQL才能获得所需的结果，而这些庞然大物的查询在SQL proc中创建起来更容易，更快捷。

只是我的两位。

有时候，您必须优化ORM正在创建的复杂事物。到那时，您通常会有一个非常复杂的查询要分解。如果您从未学习过基础知识，那么如何期望通过高级知识开始学习SQL？您甚至不了解，甚至无法开始。ORM掌握SQL，这是一个很好的工具。完全不了解SQL的人手中的ORM-灾难等待发生。

SQL对理解数据库至关重要的原因之一是，应用程序程序员自然不会考虑数据集。但是，数据库根本无法有效运行的唯一方法是按集合。在尝试使用ORM之前，您需要学习如何思考问题。

我发现自己经常在ORM框架中手动强制查询。尽管大多数查询语言都有其自己的查询语言，但它们都是受sql启发的，代码变成了sql，因此您需要（如果不是（何时，何时）出现问题或性能不佳时，通过读取sql来了解问题所在。
因此，即使您不是直接编写sql，也要对它有一个基本的了解（尽管您可能不需要学习编写存储过程，触发器等知识，如果您要做的只是访问数据库），应该了解足够的语言以理解生成的代码并根据需要对其进行调整。

在谈论这个问题之前，首先要进行一些介绍。我喜欢ORM。而且我讨厌SQL。我喜欢ORM，因为它们隐藏了SQL所带来的用户不友好的混乱，并提供了一种很好的语言集成方式来处理数据库。

但是我得承认SQL有很多好处，其中最大的好处就是精度。我只需通过查询就可以对SQL查询的复杂性争论不休，而无需了解底层数据库架构的详细知识。因此，当我使用SQL时，我总是很警惕，而且我总是对组件的复杂性前进的方向有一个直觉。

另一方面，在使用ORM时，我对数据库集成的便捷性感到不知所措，以至于我什至忘记了甚至有一个数据库。这使我很困惑。过去，我曾多次调用过看上去无辜的ORM方法，但在幕后调用了大规模而令人恐惧的数据库联接，从而破坏了性能。

这就是为什么对我来说，真相介于两者之间。我喜欢使用ORM，我将继续这样做，但是我必须更加小心，并始终研究任何ORM方法调用的含义（在SQL级别上）。知道抽象层的含义在这项业务中是纯金，并证明使用抽象是合理的。其他任何事情，就像在脚上射击自己。

如果您只需要在构建应用程序时就与数据库进行交互，则可能不需要它。在一些较小的公司或开发团队中，您可能需要提供一些支持。连接到客户端的数据库并运行一些sql语句以查看其数据的运行情况要容易得多。

即使有了一个良好，成熟的ORM，您也不可避免地会遇到这样的情况：如果您了解生成的SQL中发生的事情，它会发出一些效率低下的SQL，并使您的生活变得更加轻松。就是说，如果您非常熟悉ORM，并且知道如何为您选择的数据库使用探查器，则可以很容易地“伪造它直到完成”。

所有这些类型的问题（“我需要知道X吗？”）的答案是“如果需要，请在第一次使用它时进行学习”。

重要的是，不要因为效率低下而陷入陷阱，因为您不了解或不愿意学习有效的做事方法。

例如，在这种特定情况下，如果您意识到程序中存在一个导致PostCount用户表字段有时不正确的错误，该怎么办。

您已修复该错误，现在必须为所有用户更新PostCount。你怎么做呢？

如果您使用ORM编写一个小脚本来执行此操作，那么您的效率将会非常低。一个非常简单的SQL查询即可。

由于这些情况相当普遍，我担心您会陷入上述陷阱！

是的，您仍然需要SQL。

不要跳到认为“旧”东西不值得考虑的假设。所谓的“遗留”技术是经过时间考验后仍然存在的那些技术。我们不称Wang电脑为“传统”，它们失败了，而消失了。

如果您问我，我的银行是否可能在大型机或IBM i上使用COBOL，是否会困扰我？绝对不可以。这些都是坚如磐石，久经考验的真正技术。猜猜是什么，他们主要使用DB2 SQL。与在当月流行的语言开发的软件中相比，我对在那里的钱更加信任。

恐龙在地球上的生存时间比我们周围人类更长。如果您读过《侏罗纪公园》（是的，书比电影要好），那么我想问您，您是否真的想面对一堆超级聪明的迅猛龙，或者顽强的T-Rex，永不放弃？不要因低估“恐龙”而被咬。;-)

除了我没有经验的游戏和（主要是统计）研究之外，似乎数据库访问和操作是少数几个错误决策会导致巨大性能损失的领域之一。我坚信代码中功能更强大的数据库抽象，并且我相信linq，它将数据库操作与编程语言联系起来，为您提供该语言的所有工具（类型检查，语法检查以及您喜欢的所有东西）您的编程语言），同时仍然赋予您足够的力量去做自己想要的事情，这绝对是很棒的。不幸的是，它仍然不能总是起作用。这就是说，如果抽象层错误地进行了优化，则可能要等待几秒钟而不是微秒，或者等待几分钟而不是几秒钟来获得结果。由于这些时期非常引人注目，您必须对其进行优化，否则您的应用程序将无法工作：性能成为应用程序的最大问题。这意味着您必须更接近金属，并要保持乐观。

当我们达到处理大型数据集的程度时，例如，手工操作需要3毫秒，而让抽象层为您完成则需要100毫秒，所以一定要让抽象层为您处理它，因为您可能速度要慢30倍，但仍然足够快（可能对于大多数应用程序而言）。但是，这种情况的现实情况是，当您查看具有200 ms响应时间的手动优化解决方案，并且当抽象层为您处理该响应时，该算法仅对性能造成10倍的影响， 2秒钟的延迟，然后您会非常在意，因为它从不是那么快就变到令人痛苦的缓慢。看到关系数据库解决方案不能很好地扩展，我认为这不会在两三年后解决。这意味着在涉及较大的数据库时，您仍将不得不花相当长的时间来了解裸机，否则您的应用程序将是如此缓慢，以至于无法与竞争对手抗衡。