无论我们是否喜欢，我们中的大多数（如果不是大多数）开发人员要么定期使用数据库，要么可能有一天需要使用数据库。考虑到野外滥用和滥用的数量以及每天与数据库相关的问题的数量，可以公平地说，开发人员应该知道某些概念，即使他们没有设计或使用它们今天的数据库。所以：

对于数据库，开发人员和其他软件专业人员应了解哪些重要概念？

回应准则：

保持简短。
每个答案一个概念是最好的。

要具体。
“数据建模”可能是一项重要技能，但这究竟意味着什么？

解释你的理由。
为什么您的概念很重要？不要只说“使用索引”。不要陷入“最佳实践”中。说服您的听众去学习更多。

支持您同意的答案。
首先阅读别人的答案。一个高等级的答案比两个低等级的答案更有效。如果还有更多要添加的内容，请添加评论或引用原始内容。

不要仅仅因为它不适用于您而拒绝投票。
我们都在不同的领域工作。此处的目的是为数据库新手提供指导，以使他们对数据库设计和数据库驱动的开发有充分的基础和全面的了解，而不是争夺最重要的头衔。

开发人员应该首先了解的数据库是：数据库的作用是什么？它们既不是如何工作的，也不是如何构建的，甚至不是如何编写代码来检索或更新数据库中的数据的。但是他们是干什么的呢？

不幸的是，这一目标的答案是一个不断变化的目标。 在从1970年代到1990年代初期的数据库大杂烩中，数据库用于共享数据。 如果您使用的是数据库，并且没有共享数据，那么您要么参与了一个学术项目，要么在浪费资源，包括您自己。建立数据库和驯服DBMS是一项艰巨的任务，以至于要多次开发数据，投资回报必须非常庞大，才能与投资相称。

在过去的15年中，数据库已用于存储仅与一个应用程序关联的持久性数据。 为MySQL或Access或SQL Server建立数据库已经变得如此例行，以至于数据库几乎已成为普通应用程序的例行部分。有时，随着数据的真实价值变得明显，最初的有限任务会因任务蠕变而被推高。不幸的是，出于单一目的而设计的数据库在开始被推到整个企业范围且对任务至关重要的角色时，往往会严重失败。

开发人员要了解数据库的第二件事是对整个数据中心视图的了解。以数据为中心的世界视图与以过程为中心的世界视图相比，大多数开发人员所学到的东西都与以往有更多不同。与该差距相比，结构化编程与面向对象编程之间的差距相对较小。

至少在概述中，开发人员需要学习的第三件事是数据建模，包括概念数据建模，逻辑数据建模和物理数据建模。

从数据中心的角度来看，概念数据建模实际上是需求分析。

逻辑数据建模通常是将特定数据模型应用于概念数据建模中发现的需求。关系模型的使用远远超过其他任何特定模型，并且开发人员需要确定地学习关系模型。针对非平凡的需求设计功能强大且相关的关系模型并非易事。如果您误解了关系模型，就无法构建好的SQL表。

物理数据建模通常是特定于DBMS的，除非开发人员同时也是数据库构建者或DBA，否则无需对其进行详细了解。开发人员确实需要了解的是，物理数据库设计可以与逻辑数据库设计分离的程度，以及仅通过调整物理设计就可以完成生成高速数据库的程度。

开发人员接下来需要了解的是，尽管速度（性能）很重要，但是其他设计优良性的衡量标准甚至更加重要，例如修改和扩展数据库范围的能力或编程的简便性。

最后，任何与数据库打交道的人都需要了解，数据的价值通常比捕获数据的系统的价值还要高。

ew！

好问题。以下是一些未按特定顺序排列的想法：

1. 至少要归为第二范式的规范化是必不可少的。

2. 参照完整性也是必不可少的，需要适当地级联删除和更新注意事项。

3. 正确使用检查约束。让数据库做更多的工作。

4. 不要将业务逻辑分散在数据库和中间层代码中。选择一个或另一个，最好使用中间层代码。

5. 确定主键和群集键的一致方法。

6. 不要过度索引。明智地选择索引。

7. 表和列的命名一致。选择一个标准并坚持下去。

8. 限制数据库中将接受空值的列数。

9. 不要被扳机带走。它们有其用途，但可以使事情复杂化。

10. 使用UDF时要小心。它们很棒，但是当您不知道它们在查询中被调用的频率时，可能会导致性能问题。

11. 获取Celko关于数据库设计的书。这个人傲慢自大，但知道自己的东西。

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

其次，出于不同的目的有不同的数据库设置。如果有可用的数据仓库，您不希望开发人员从在线事务数据库中制作历史报告。

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

除此之外，这取决于开发人员的参与程度。我曾经从事过开发人员和事实上的DBA的工作，DBA刚走过通道，而DBA不在自己的工作范围内。（我不喜欢第三个。）假设开发人员参与数据库设计：

他们需要了解基本规范化，至少是前三种规范形式。除此之外，请获取DBA。对于那些在美国法庭上有过任何经验的人（这里包括随机电视节目），助记符“取决于键，整个键，而仅取决于键，所以请帮助您Codd”。

他们需要对索引有所了解，我的意思是他们应该对他们需要什么索引以及它们可能如何影响性能有所了解。这意味着没有无用的索引，但又不怕添加索引以辅助查询。任何其他事项（例如余额）都应留给DBA。

他们需要了解数据完整性的需求，并能够指出他们在验证数据的位置以及发现问题时的操作。这不必位于数据库中（在该数据库中很难为用户发出有意义的错误消息），而必须位于某个地方。

他们应该具有如何获得计划以及如何阅读计划的基本知识（至少足以告诉他们算法是否有效）。

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

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

我无疑忘记了一些东西，但是只要手头有一个真正的DBA，一般的开发人员就不必是DBA。

基本索引

看到没有索引或任意/无用索引的表或整个数据库，我总是感到震惊。即使您不是在设计数据库，而只需要编写一些查询，理解它仍然至关重要，至少要：

• 数据库中已索引的内容和未索引的内容：
• 扫描类型，选择方式以及编写查询方式如何影响选择之间的差异；
• 覆盖的概念（为什么不应该只写SELECT *）；
• 聚集索引和非聚集索引之间的区别；
• 为什么更多/更大的索引不一定会更好？
• 为什么要避免在函数中包装过滤器列。

设计人员还应该注意常见的索引反模式，例如：

• Access反模式（索引每一列，一个接一个）
• Catch-All反模式（在所有或大多数列上都有一个庞大的索引，显然是在错误的印象下创建的，即它会加快涉及这些列中任何一个的所有可能的查询的印象）。

数据库索引的质量（以及是否在编写的查询中利用索引）是迄今为止最重要的性能。在SO和其他论坛上发布的10个问题中，有9个抱怨性能不佳总是归因于索引编制不佳或表达式无法保留。

正常化

总是让我感到沮丧的是，有人在努力编写一个过于复杂的查询，而使用规范化的设计本来就很简单（“向我显示每个地区的总销售额。”）。

如果您一开始就理解了这一点并进行了相应的设计，那么以后您将省去很多麻烦。规范化后，很容易对性能进行非规范化；标准化从一开始就不是这样设计的数据库并非易事。

至少，您应该知道3NF是什么以及如何到达那里。对于大多数事务数据库，这在使查询易于编写和保持良好性能之间取得了很好的平衡。

索引如何工作

它可能不是最重要的，但肯定是最被低估的主题。

索引的问题在于，SQL教程通常根本不会提及它们，并且所有玩具示例都可以在没有任何索引的情况下工作。

甚至比“ 索引使查询快速 ”，甚至更多有经验的开发人员也可以编写相当好（复杂）的SQL，而无需了解更多有关索引的知识。

这是因为SQL数据库作为黑盒子工作非常出色：

告诉我您需要什么（大型SQL），我会解决的。

这非常适合检索正确的结果。SQL的作者不需要知道系统在幕后正在做什么-直到所有事情变得如此缓慢.....

那就是索引成为主题的时候。但这通常很晚，有人（某些公司？）已经遇到了实际问题。

这就是为什么我认为索引是使用数据库时不要忘记的第一主题。不幸的是，很容易忘记它。

免责声明

这些论点是从我的免费电子书“ Use the Index，Luke ” 的序言中借用的。我花了大量时间解释索引如何工作以及如何正确使用它们。

我只想指出一个观察结果，那就是似乎大多数答复都认为数据库可以与关系数据库互换。还有对象数据库，平面文件数据库。评估手头软件项目的需求很重要。从程序员的角度来看，数据库决策可以延迟到以后。另一方面，可以尽早实现数据建模并取得巨大成功。

我认为数据建模是一个关键组件，并且是一个相对较旧的概念，但它却已被软件行业中的许多人所忘记。数据建模，特别是概念建模，可以揭示系统的功能行为，并且可以作为开发的路线图。

另一方面，可以基于许多不同因素来确定所需的数据库类型，这些因素包括环境，用户数量以及可用的本地硬件（例如硬盘空间）。

避免SQL 注入以及如何保护数据库

每个开发人员都应该知道这是错误的：“对数据库操作进行概要分析与对代码进行概要分析完全不同。”

传统意义上有一个清晰的Big-O。当您执行EXPLAIN PLAN（或等效操作）时，您会看到算法。一些算法涉及嵌套循环，并且为O（n ^ 2）。其他算法涉及B树查找，并且为O（n log n）。

这是非常非常严重的。了解索引为何重要的关键。了解速度标准化-非标准化折衷的关键。理解为什么数据仓库使用星型模式（对于事务更新未规范化）至关重要。

如果您不清楚所使用的算法，请执行以下操作。停止。解释查询执行计划。相应地调整索引。

另外，必然结果是：更多的索引不是更好。

有时，针对一个操作的索引会使其他操作变慢。根据两个操作的比率，添加索引可能会产生良好的效果，没有整体影响，或者对整体性能有害。

我认为每个开发人员都应该了解数据库需要不同的范例。

在编写查询以获取数据时，需要一种基于集合的方法。许多具有互动背景的人为此感到挣扎。但是，当他们接受它时，即使解决方案可能并不是最初以迭代为重点的解决方案，也可以取得更好的结果。

很好的问题。让我们看看，首先没有人应该考虑查询一个不完全了解联接的datbase。这就像在不知道方向盘和制动器在哪里的情况下驾驶汽车。您还需要了解数据类型以及如何选择最佳数据类型。

开发人员应了解的另一件事是，在设计数据库时应牢记三件事：

1. 数据完整性-如果不能依靠数据，而您基本上没有数据-这意味着不要在应用程序中放置所需的逻辑，因为许多其他来源可能会接触数据库。约束，外键以及有时是触发器对于数据完整性是必需的。不要因为您不喜欢它们或不想被他们理解而使用它们。

2. 性能-很难重构性能低下的数据库，应该从一开始就考虑性能。有许多方法可以执行相同的查询，并且有些方法几乎总是可以更快地进行，因此不学习和使用这些方法是短视的。在设计查询或数据库结构之前，请阅读一些有关性能调优的书。

3. 安全性-这些数据是您公司的命脉，也经常包含可以被窃取的个人信息。了解如何保护您的数据免受SQL注入攻击，欺诈和身份盗用。

查询数据库时，很容易得到错误的答案。确保您彻底了解数据模型。请记住，经常会根据查询返回的数据做出实际的决定。错误时，将做出错误的业务决策。您可以通过不好的查询杀死一家公司或失去大客户。数据具有意义，开发人员似乎常常忘记这一点。

数据几乎永远不会消失，请考虑随着时间的推移存储数据，而不仅仅是今天如何获取数据。拥有十万条记录的数据库可以正常工作，十年后可能就不会那么好了。应用程序很少能持续到数据那么长时间。这就是为什么性能设计至关重要的原因之一。

您的数据库可能会需要应用程序不需要查看的字段。诸如用于复制的GUID，日期插入字段之类的东西。等。您可能还需要存储更改的历史记录以及更改的历史记录，以及何时可以从该存储库中恢复错误的更改。在问一个网站之前，想一想您打算如何做，以解决您忘记在更新中放置where子句并更新整个表的问题。

永远不要在比生产版本更高的数据库版本中进行开发。永不永不直接针对生产数据库进行开发。

如果您没有数据库管理员，请确保有人在进行备份并知道如何还原它们，并已测试了还原它们的能力。

数据库代码就是代码，没有任何理由不像其他代码一样将其保留在源代码控制中。

进化数据库设计。http://martinfowler.com/articles/evodb.html

这些敏捷的方法使数据库更改过程可管理，可预测和可测试。

开发人员应该知道，在版本控制，持续集成和自动化测试方面，重构生产数据库需要做什么。

演化数据库设计过程具有管理方面的内容，例如，在此生存期之后，将在此代码库的所有数据库中删除一列。

至少知道，存在数据库重构的概念和方法。 http://www.agiledata.org/essays/databaseRefactoringCatalog.html

分类和过程描述也使得为这些重构实现工具成为可能。

根据我在关系数据库方面的经验，每个开发人员都应该知道：

-不同的数据类型：

为正确的工作使用正确的类型将使您的数据库设计更健壮，查询更快，生活更轻松。

-了解1xM和MxM：

这是关系数据库的基础。您需要了解一对多和多对多的关系，然后在适当时应用。

-“ KISS ”原则也适用于数据库：

简单总是最好的。只要您已经研究了数据库的工作原理，就可以避免不必要的复杂性，从而避免维护和速度问题。

-指标：

知道它们是什么还不够。您需要了解何时使用它们，何时不使用它们。

也：

• 布尔代数是你的朋友
• 图像：不要将它们存储在数据库中。不要问为什么。
• 使用SELECT测试DELETE

我希望每个人，包括DBA和开发人员/设计人员/架构师，都更好地了解如何正确地对业务域进行建模，以及如何将该业务域模型映射/转换为规范化的数据库逻辑模型，优化的物理模型和模型。适当的面向对象的类模型，由于各种原因，每个模型都（可以）不同，并且了解它们何时，为什么以及如何彼此不同（或应该彼此不同）。

我会说很强的基本SQL技能。到目前为止，我已经看到很多开发人员，他们对数据库有些了解，但是总是在寻求有关如何编写一个非常简单的查询的提示。查询并不总是那么容易和简单。查询规范化良好的数据库时，必须使用多个联接（内部，左侧等）。

关于Walter M.的回答的以下评论：

“写得很好！对于那些当时没有从事数据库工作的人（即我）来说，历史观点非常有用”。

从某种意义上讲，历史观点绝对至关重要。“那些忘记历史的人注定要重蹈覆辙。” Cfr XML重复了过去的层次化错误，图形数据库重复了过去的网络错误，OO系统将层次结构模型强加于用户，而每个人甚至只有十分之一的大脑都应该知道，层次结构模型不适合通用-真实世界等的目的表示。

至于问题本身：

每个数据库开发人员都应该知道“关系”不等于“ SQL”。然后他们会理解为什么DBMS供应商会如此失望，以及为什么他们要告诉同样的供应商想出更好的东西（例如真正具有关系的DBMS），如果他们想继续吸纳大量的他们的客户从这种糟糕的软件中赚钱）。

每个数据库开发人员都应该了解有关关系代数的所有知识。这样一来，不再有一个开发人员不得不在Stack Overflow上发布这些愚蠢的“我不知道如何做我的工作，并希望其他人为我做”的愚蠢问题。

我认为这里已经涵盖了许多技术细节，并且我不想对其进行补充。我想说的一件事是社交而非技术，不要落入应用程序开发人员的“ DBA知道最好”的陷阱。

如果您在查询中遇到性能问题，请也负责解决问题。做您自己的研究并推动DBA解释正在发生的事情以及他们的解决方案如何解决该问题。

完成研究后，也要提出自己的建议。也就是说，我试图找到一种针对该问题的合作解决方案，而不是将数据库问题留给DBA。

简单的尊重。

• 不只是一个仓库
• 您可能并不比供应商或DBA更了解
• 您不会在凌晨3点支持它，而高级经理会大声地对您大喊

将非规范化视为可能的天使，而不是魔鬼，并且还将NoSQL数据库视为关系数据库的替代方法。

另外，即使您不设计数据库，我也认为实体关系模型是每个开发人员都必须知道的。它可以让您彻底了解数据库的全部内容。

切勿以错误的文本编码插入数据。

一旦您的数据库被多种编码污染，您最好的办法就是将启发式方法和体力劳动结合起来。

除了它们使用的语法和概念选项（例如联接，触发器和存储过程）外，对于每个使用数据库的开发人员来说至关重要的是：

知道您的引擎将如何具体执行正在编写的查询。

我认为这很重要的原因仅仅是生产稳定性。您应该知道代码的执行方式，因此在等待较长的函数完成时不会停止线程中的所有执行，所以为什么不希望知道查询将如何影响数据库，程序，甚至服务器？

实际上，与缺少分号之类的东西相比，这对我的研发团队影响更大。假定查询将很快执行，因为查询是在其开发系统上执行的，表中只有几千行。即使生产数据库的大小相同，它也很有可能会更多地被使用，从而遭受其他限制，例如多个用户同时访问它，或者其他地方的另一个查询出了问题，从而延迟了此查询的结果。

即使简单的事情（如联接如何影响查询性能）在生产中也无价。许多数据库引擎的许多功能在概念上使事情变得更容易，但是如果没有清楚地考虑，可能会在性能上引入陷阱。

了解您的数据库引擎执行过程并为其计划。

对于经常使用数据库（每天或几乎每天编写/维护查询）的中级专业开发人员，我认为期望应该与任何其他领域相同：您在大学里写过一个。

每个C ++怪胎在大学里都写过一个字符串类。每个图形极客在大学里都写了一个光线追踪器。每个网络极客都在大学里编写了交互式网站（通常在我们拥有“网络框架”之前）。每个硬件书呆子（甚至是软件书呆子）在大学里都建立了一个CPU。每个医生都解剖了整个大学的尸体，即使她只是要测量我的血压并告诉我今天我的胆固醇过高。为什么数据库会有所不同？

不幸的是，由于某种原因，今天它们确实有所不同。人们希望.NET程序员知道字符串在C语言中是如何工作的，但是RDBMS的内部不必太在意您。

从阅读它们甚至从上而下的工作中，获得相同的理解水平几乎是不可能的。但是，如果您从头开始并理解每一部分，那么找出数据库的细节相对容易。即使是许多数据库极客也看不到的东西，例如何时使用非关系数据库。

也许这有点严格，尤其是如果您没有在大学学习计算机科学的话。我会对此加以说明：您今天可以完全从头开始编写一个。我不在乎您是否了解PostgreSQL查询优化器的工作原理，但如果您知道足以自己编写一个，则可能与他们所做的没有太大不同。而且您知道，写一个基本的书并不难。

非唯一索引中列的顺序很重要。

第一列应该是内容变化最大的列（即基数）。

这是为了帮助SQL Server能够创建有关如何在运行时使用索引的有用统计信息。

了解用于编程数据库的工具！！！

我浪费了很多时间试图理解为什么我的代码神秘地失败了。

例如，如果使用的是.NET，则需要知道如何正确使用System.Data.SqlClient命名空间中的对象。您需要知道如何管理SqlConnection对象，以确保它们已打开，关闭，并在必要时正确处理。

您需要知道，当您使用时SqlDataReader，有必要单独关闭它SqlConnection。您需要了解如何在适当的时候使连接保持打开状态，以最大程度地减少对数据库的访问次数（因为在计算时间上它们相对昂贵）。

• 基本的SQL技能。
• 索引。
• 处理DATE / TIME / TIMESTAMP的不同形式。
• 您正在使用的平台的JDBC驱动程序文档。
• 处理二进制数据类型（CLOB，BLOB等）

对于某些项目，面向对象模型更好。

对于其他项目，关系模型更好。

阻抗不匹配问题，并知道常见的缺陷或ORM。

RDBMS兼容性

查看是否需要在多个RDBMS中运行该应用程序。如果是，则可能有必要：

• 避免RDBMS SQL扩展
• 消除触发器并存储程序
• 遵循严格的SQL标准
• 转换字段数据类型
• 更改事务隔离级别

否则，这些问题应分开处理，并将开发该应用程序的不同版本（或配置）。

不要依赖于SQL查询返回的行的顺序。

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/