不管我们喜欢与否，我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库，或者有一天可能不得不使用数据库。考虑到大量的误用和滥用，以及每天出现的大量与数据库相关的问题，公平地说，有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库，开发人员和其他软件专业人员应该知道的一个重要概念是什么?
当前回答
每个开发人员都应该知道这是错误的:“分析数据库操作与分析代码完全不同。”
在传统意义上有一个明确的Big-O。当你做一个EXPLAIN PLAN(或等效)时，你看到的是算法。有些算法涉及嵌套循环，并且是O(n ^ 2)。其他算法涉及到b树查找，并且是O(n log n)。
这是非常非常严重的。这是理解为什么索引很重要的关键。这对于理解速度-标准化-非标准化之间的权衡至关重要。这对于理解为什么数据仓库使用星型模式是非常重要的，而星型模式并没有对事务更新进行规范化。
如果您不清楚所使用的算法，请执行以下操作。停止。解释查询执行计划。相应调整指标。
同样，结论是:索引越多越好。
有时，专注于一个操作的索引会降低其他操作的速度。根据这两个操作的比例，添加一个索引可能有良好的效果，也可能没有整体影响，或者对整体性能不利。
其他回答
我想这里已经介绍了很多技术细节，我不想再补充了。我想说的一件事是，社交比技术更重要，作为应用程序开发人员，不要陷入“DBA知道最好的”的陷阱。
如果您在查询方面有性能问题，也要解决这个问题。自己进行研究，并要求dba解释发生了什么，以及他们的解决方案是如何解决问题的。
在你做了研究之后，也要提出你自己的建议。也就是说，我试图找到解决问题的合作解决方案，而不是将数据库问题留给dba。
关于以下对Walter M。的回答:
“写得很好!历史视角对于当时没有做数据库工作的人(比如我)来说非常有用。”
历史观点在某种意义上是绝对重要的。“忘记历史的人，注定要重蹈覆辙。”XML重复着过去的层次错误，图形数据库重复着过去的网络错误，OO系统迫使用户使用层次模型，而每个人即使只有十分之一的大脑都应该知道层次模型不适合真实世界的通用表示，等等，等等。
至于问题本身:
每个数据库开发人员都应该知道“关系型”不等于“SQL”。然后他们就会明白为什么他们会被DBMS供应商如此失望，为什么他们应该告诉同样的供应商想出更好的东西(例如真正的关系型DBMS)，如果他们想继续从他们的客户那里为这些蹩脚的软件吸走大量的钱)。
每个数据库开发人员都应该了解关系代数的所有知识。这样，就不会再有开发者在Stack Overflow网站上发布“我不知道如何做我的工作，希望别人帮我做”这样的愚蠢问题了。
了解用于数据库编程的工具!!
我浪费了很多时间试图理解为什么我的代码神秘地失败了。
例如，如果您正在使用。net，您需要知道如何正确使用System.Data.SqlClient名称空间中的对象。您需要知道如何管理SqlConnection对象，以确保它们被打开、关闭，并在必要时正确地处理。
你需要知道，当你使用SqlDataReader时，有必要将它与你的SqlConnection分开关闭。您需要了解如何在适当的时候保持连接打开，以及如何最小化对数据库的访问次数(因为它们在计算时间方面相对昂贵)。
索引的工作原理
这可能不是最重要的，但肯定是最被低估的话题。
索引的问题在于SQL教程通常根本不会提到它们，而且所有的玩具示例都可以在没有索引的情况下工作。
即使更有经验的开发人员也可以编写相当好的(和复杂的)SQL，而不需要了解更多关于索引的知识，而只是“索引使查询更快”。
这是因为SQL数据库作为黑盒的工作做得非常好:
告诉我你需要什么(给我SQL)，我来处理。
这可以很好地检索正确的结果。SQL的作者不需要知道系统在幕后做什么——直到一切变得非常缓慢.....
这时索引就成了一个话题。但这通常很晚了，而且某些人(一些公司?)已经遇到了真正的问题。
这就是为什么我认为索引是在使用数据库时不能忘记的首要主题。不幸的是，它很容易忘记。
免责声明
这些论点是从我的免费电子书“使用索引，卢克”的序言中借来的。我花了很多时间来解释索引是如何工作的，以及如何正确地使用它们。
归一化
我总是很沮丧地看到有人努力编写一个过度复杂的查询，而这个查询用标准化的设计可以完全简单明了(“显示每个地区的总销售额。”)。
如果您在一开始就理解了这一点，并相应地进行设计，您将在以后为自己省去许多痛苦。在规范化之后，很容易对性能进行反规范化;要规范化一个从一开始就不是这样设计的数据库并不容易。
至少，您应该知道3NF是什么以及如何实现它。对于大多数事务性数据库，这是使查询易于编写和保持良好性能之间的一个很好的平衡。
