伟大的 SQL 开发人员的标志答案

【问题标题】：Signs of a great SQL developer伟大的 SQL 开发人员的标志
【发布时间】：2008-11-15 18:33:34
【问题描述】：

根据他们的工作，您如何区分优秀的 SQL 开发人员？

示例可能包括：

很少使用 CURSOR，并尝试将它们重构掉。
很少使用临时表，并尝试将它们重构掉。
自信地处理 OUTER JOIN 中的 NULL 值。
避免未广泛实施的 SQL 扩展。知道如何优雅地缩进。

【问题讨论】：

是否有人请澄清评论“很少使用 CURSOR，并试图将它们重构掉。”？我在一个中型 HR 系统上工作，并且在对几千到几万条记录进行批量更新时，经常使用游标。如果不使用游标，这将如何完成？
您能否举一个您当前使用光标的业务流程操作示例？
业务部门 103 的 2000 名员工于 2012 年 3 月 1 日采取终止行动。我想在 2012 年 3 月 2 日为这些员工添加雇用操作并更新他们的工资记录。每个员工的最高记录中的一些字段将被转移到新的操作和记录中。我如何在没有光标的情况下获取这些员工行为和支付记录？如果有帮助，该系统会模仿 Peoplesoft 系统。
你不会自然而然地做类似 SELECT fields FROM terminates WHERE business_unit = '103' AND action_date = '01-MAR-2012' 之类的事情吗？然后用它来构造“INSERT INTOhire_actions (fields....) SELECT etc.” （根据需要添加连接和表达式？对于支付记录，从最高记录中选择以构造 INSERT 和 UPDATE 语句？即使使用游标，您也可能需要做大致相同的事情。只需对其进行集合操作即可在一份声明中处理所有员工。
啊。我懂了。建议将所有代码放在一条 SQL 语句中。对于简单的更新可能没问题，但对于需要更复杂逻辑的程序，这可能会使 SQL 变得非常笨拙且难以排除故障。让我想回去检查我的旧程序。当我有时间时，我想我会去看看其中一些是否可以优化。感谢您的澄清。

标签： sql

【解决方案1】：

我发现优秀的 SQL 开发人员通常也是优秀的数据库设计师，并且更愿意参与数据库的设计和实现。这是因为糟糕的数据库设计甚至会阻碍和阻碍最优秀的开发人员——良好的 SQL 直觉在面对病态设计或 RI 很差或不存在的系统时并不总是能正常工作。因此，告诉优秀 SQL 开发人员的一种方法是对他们进行数据建模测试。

此外，优秀的数据库开发人员必须具备复杂的联接逻辑，并且准确了解各种多路联接在不同情况下的结果。缺乏对连接的舒适度是糟糕的 SQL 代码（以及糟糕的 SQL 设计，就此而言）的第一大原因。

至于具体的语法，我会犹豫如下指令：

不使用 CURSOR。

不使用临时表。

使用这些技术可以让您区分危险的业余 SQL 程序员（当简单的关系谓词会更好时使用它们）和体面的入门 SQL 程序员（知道如何在没有它们的情况下完成大多数事情）之间的区别.然而，在现实世界的使用中有很多情况，其中临时表和游标是完成事情的完全合适的方式（有时是唯一的方式）（没有移动到另一层进行处理，这有时会更好）。

因此，并不禁止使用此类高级概念，但除非您明确与一位 SQL 专家打交道，该专家正在处理一个非常棘手的问题，由于某种原因，该问题不适合关系解决方案...... . 是的，它们可能是警告信号。

【讨论】：

我特别喜欢关于错误分区功能的评论。我认为这通常是使用游标 - dbms 被用于解决其他层的问题。
而且，与大多数事情一样......“这取决于”。各种架构和模糊原因可能会说服人们在 DB 上编写更适合在另一层上的代码，而这些高级 DB 功能在那些时候很有用。

【解决方案2】：

我不认为游标、临时表或其他 SQL 做法天生就不好，也不认为它们的使用是数据库程序员有多优秀的明显标志。

我认为每种类型的问题都有合适的工具。当然，如果你只有一把锤子，一切看起来都像钉子。我认为优秀的 SQL 程序员或数据库开发人员知道在特定情况下哪种工具是正确的。恕我直言，您不能概括排除特定模式。

但经验法则可能是：对于复杂的情况，优秀的数据库开发人员会比普通程序员找到更简短而优雅的解决方案。

【讨论】：

【解决方案3】：

以下几点不适用于普通软件开发人员，但适用于具备良好 SQL 技能的人：

定义有用的索引，但不定义冗余或未使用的索引。
有效地使用交易。
重视参照完整性。
将规范化应用于数据库设计。
考虑集合，而不是循环。
自信地使用 JOIN。
了解 NULL 和三值逻辑的工作原理。
了解查询参数的用途和好处。

您给出的示例，不使用游标、临时表或不知道给定任务的 3 个替代查询，我会不考虑成为一名出色的 SQL 开发人员的迹象。也许我会把做这些事情的人称为“acrobat”。

【讨论】：

这些是优秀 SQL 开发人员的标志，但我认为它们不足以区分“优秀”开发人员。
好的，限定词有保守的杂技演员和愚蠢的杂技演员。
是的，我就是这个意思。杂技演员可以表现出令人印象深刻的艺术性、技巧和才能。但通常有更简单的方法可以从 A 点到达 B 点。

【解决方案4】：

只是为了补充已经很好的答案；开发人员可以将复杂问题简化为简单且易于维护。

【讨论】：

很酷，很好的笼统，模糊，不是真正添加任何价值的答案！

【解决方案5】：

知道如何使用 INFORMATION_SCHEMA 和表元数据来编写通用代码或生成代码以节省重复的数据库任务。

【讨论】：