归一化

我总是很沮丧地看到有人努力编写一个过度复杂的查询，而这个查询用标准化的设计可以完全简单明了(“显示每个地区的总销售额。”)。

如果您在一开始就理解了这一点，并相应地进行设计，您将在以后为自己省去许多痛苦。在规范化之后，很容易对性能进行反规范化;要规范化一个从一开始就不是这样设计的数据库并不容易。

至少，您应该知道3NF是什么以及如何实现它。对于大多数事务性数据库，这是使查询易于编写和保持良好性能之间的一个很好的平衡。

除了他们使用的语法和概念选项(例如连接、触发器和存储过程)之外，对于每个使用数据库的开发人员来说，有一件事是至关重要的:

了解您的引擎将如何执行您正在编写的查询。

我认为这很重要的原因仅仅是生产的稳定性。您应该知道您的代码是如何执行的，这样您就不会在等待一个长函数完成时停止线程中的所有执行，那么为什么您不想知道您的查询将如何影响数据库、程序甚至服务器呢?

This is actually something that has hit my R&D team more times than missing semicolons or the like. The presumtion is the query will execute quickly because it does on their development system with only a few thousand rows in the tables. Even if the production database is the same size, it is more than likely going to be used a lot more, and thus suffer from other constraints like multiple users accessing it at the same time, or something going wrong with another query elsewhere, thus delaying the result of this query.

即使是像连接如何影响查询性能这样简单的事情，在生产中也是非常宝贵的。许多数据库引擎的许多特性在概念上让事情变得更简单，但如果没有考虑清楚，可能会在性能上带来问题。

了解数据库引擎的执行过程，并为之制定计划。

三件事是一个神奇的数字:

数据库也需要版本控制。 游标很慢，您可能不需要它们。 触发器是邪恶的*

*几乎总是

首先，开发人员需要了解一些关于数据库的知识。它们不仅仅是输入SQL并得到结果集的神奇设备，而是具有自己的逻辑和癖好的非常复杂的软件。

其次，针对不同的目的有不同的数据库设置。如果有可用的数据仓库，则不希望开发人员从联机事务数据库生成历史报告。

第三，开发人员需要了解基本的SQL，包括连接。

除此之外，它还取决于开发人员参与的程度。我曾经工作过，我是开发人员，实际上是DBA, DBA只是在走道的另一边，而DBA则在各自的领域。(我不喜欢第三个。)假设开发人员参与了数据库设计:

他们需要了解基本的标准化，至少是前三种标准形式。除此之外，请找一个DBA。对于那些有过美国法庭(以及随便看的电视节目)经验的人来说，有一句便于记忆的话:“依靠钥匙，全部的钥匙，除了钥匙别无其他，帮你一把，科德。”

他们需要了解索引，我的意思是他们应该知道他们需要什么索引，以及它们可能如何影响性能。这意味着不要使用无用的索引，但不要害怕添加它们来辅助查询。任何进一步的工作(如余额)都应该留给DBA。

他们需要理解对数据完整性的需求，并能够指出他们在哪里验证数据，以及如果发现问题他们正在做什么。这并不一定要在数据库中(在数据库中很难向用户发出有意义的错误消息)，但必须在某个地方。

他们应该具备如何制定计划的基本知识，以及如何大体阅读计划(至少足以判断算法是否有效)。

他们应该模糊地知道什么是触发器，什么是视图，以及可以对数据库进行分区。他们不需要任何细节，但他们需要知道如何向DBA询问这些事情。

他们当然应该知道不要干涉生产数据，或生产代码，或类似的东西，他们应该知道所有的源代码都进入VCS。

毫无疑问，我忘记了一些事情，但是一般的开发人员不需要是DBA，前提是手头有一个真正的DBA。

我会说有很强的SQL基础技能。到目前为止，我见过许多对数据库了解不多的开发人员，但总是询问如何制定一个相当简单的查询的技巧。查询并不总是那么容易和简单。在查询规范化良好的数据库时，必须使用多个连接(内部连接、左连接等)。

关于以下对Walter M。的回答:

“写得很好!历史视角对于当时没有做数据库工作的人(比如我)来说非常有用。”

历史观点在某种意义上是绝对重要的。“忘记历史的人，注定要重蹈覆辙。”XML重复着过去的层次错误，图形数据库重复着过去的网络错误，OO系统迫使用户使用层次模型，而每个人即使只有十分之一的大脑都应该知道层次模型不适合真实世界的通用表示，等等，等等。

至于问题本身:

每个数据库开发人员都应该知道“关系型”不等于“SQL”。然后他们就会明白为什么他们会被DBMS供应商如此失望，为什么他们应该告诉同样的供应商想出更好的东西(例如真正的关系型DBMS)，如果他们想继续从他们的客户那里为这些蹩脚的软件吸走大量的钱)。

每个数据库开发人员都应该了解关系代数的所有知识。这样，就不会再有开发者在Stack Overflow网站上发布“我不知道如何做我的工作，希望别人帮我做”这样的愚蠢问题了。