无论我们是否喜欢，很多人（如果不是大多数）开发人员要么经常使用数据库，要么可能有一天必须使用数据库 . 考虑到野外滥用和滥用的数量，以及每天出现的数据库相关问题的数量，可以说开发人员应该知道某些概念 - 即使他们没有设计或使用数据库今天 . 所以：
开发人员和其他软件专业人员应该了解的有关数据库的重要概念是什么？
回应指南：
Keep your list short.
每个答案的一个概念是最好的 .
Be specific .
"Data modelling"可能是一项重要技能，但这究竟意味着什么呢？
Explain your rationale.
为什么你的概念很重要？唐"best practices."吨落入"best practices."说服你的 Spectator 去了解更多 .
Upvote answers you agree with.
首先阅读其他人的答案 . 一个排名较高的答案是比两个排名较低的答案更有效的陈述 . 如果您要添加更多内容，请添加评论或引用原始评论 .
Don't downvote something just because it doesn't apply to you personally.
我们都在不同的领域工作 . 这里的目标是为数据库新手提供指导，以获得对数据库设计和数据库驱动开发的有充分理解和全面理解，而不是争夺最重要的 Headers .
30 回答
开发人员应该了解数据库的第一件事是： what are databases for ？它们不是如何工作的，也不是如何构建它们，甚至不是如何编写代码来检索或更新数据库中的数据 . 但它们是为了什么？
不幸的是，这个答案是一个不断变化的目标 . In the heydey of databases, the 1970s through the early 1990s, databases were for the sharing of data. 如果您使用的是数据库，并且您没有共享数据，那么您要么参与学术项目，要么浪费资源，包括您自己 . Build 一个数据库并驯服DBMS是一项巨大的任务，就多次利用数据而言，回报必须与投资相匹配 .
Over the last 15 years, databases have come to be used for storing the persistent data associated with just one application. 为MySQL或Access或SQL Server构建数据库已变得如此常规，以至于数据库几乎已成为普通应用程序的常规部分 . 有时，随着数据的真实 Value 变得明显，最初的有限任务会被任务蠕变推升 . 遗憾的是，设计时考虑到单一目的的数据库在开始被推入企业范围和关键任务的角色时经常会失败 .
开发人员需要了解的关于数据库的第二件事是整个世界 . 与以流程为中心的世界观相比，以数据为中心的世界观与大多数开发人员所学到的不同 . 与此差距相比，结构化编程和面向对象编程之间的差距相对较小 .
开发人员需要学习的第三件事，至少在概述中，是数据建模，包括概念数据建模，逻辑数据建模和物理数据建模 .
Conceptual data modeling 实际上是从数据中心的角度进行需求分析 .
Logical data modeling 通常是将特定数据模型应用于概念数据建模中发现的需求 . 关系模型的使用远远超过任何其他特定模型，开发人员需要确保学习关系模型 . 为一项重要的要求设计一个强大而相关的关系模型并非易事 . 如果您误解了关系模型，则无法构建良好的SQL表 .
Physical data modeling 通常是特定于DBMS的，除非开发人员也是数据库构建器或DBA，否则不需要详细了解 . 开发人员需要了解的是物理数据库设计与逻辑数据库设计的分离程度，以及通过调整物理设计可以实现高速数据库生成的程度 .
开发人员需要学习的下一件事是 while speed (performance) is important, other measures of design goodness are even more important ，例如修改和扩展数据库范围的能力，或编程的简单性 .
最后，任何与数据库混淆的人都需要了解 the value of data often outlasts the system that captured it .
呼！
好问题 . 以下是一些没有特别顺序的想法：
归一化，至少是第二种正常形式，是至关重要的 .
参考完整性也很重要，具有适当的级联删除和更新注意事项 .
正确使用检查约束 . 让我们数据库做尽可能多的工作 .
不要在数据库和中间层代码中分散业务逻辑 . 选择一个或另一个，最好是中间层代码 .
确定主键和群集密钥的一致方法 .
不要过度索引 . 明智地选择你的指数 .
一致的表和列命名 . 选择标准并坚持下去 .
限制数据库中将接受空值的列数 .
不要被触发器带走 . 它们有它们的用途，但可以使事情匆忙复杂化 .
小心使用UDF . 它们很棒，但是当您不知道在查询中调用它们的频率时，可能会导致性能问题 .
获取Celko关于数据库设计的书 . 这个男人很傲慢但知道他的东西 .
首先，开发人员需要了解有关数据库的知识 . 它们不仅仅是你放入SQL并获取结果集的神奇设备，而是具有自己的逻辑和怪癖的非常复杂的软件 .
其次，存在用于不同目的的不同数据库设置 . 如果有可用的数据仓库，您不希望开发人员从在线事务数据库中创建历史报告 .
第三，开发人员需要了解基本的SQL，包括连接 .
过去，这取决于开发人员的参与程度 . 我曾在那些我是开发人员和事实上的DBA的工作中工作过，而DBA就在那里，而DBA在他们自己的领域已经关闭了 . （我不喜欢第三个 . ）假设开发人员参与数据库设计：
他们需要了解基本的标准化，至少是前三种正常形式 . 除此之外，还有一个DBA . 对于那些有美国法庭经验（以及随机电视节目在这里）的人来说，有一个助记符“取决于钥匙，整个钥匙，除了关键，所以帮助你Codd . ”
他们需要对索引有一个线索，我的意思是他们应该知道他们需要什么样的索引以及它们可能如何影响性能 . 这意味着没有无用的索引，但不要害怕添加它们来协助查询 . 应该留给DBA更进一步（比如余额） .
他们需要了解数据完整性的必要性，并能够指出他们验证数据的位置以及他们发现问题时他们正在做什么 . 这不必在数据库中（对于用户来说很难发出有意义的错误消息），但必须在某个地方 .
他们应该具备如何获得计划的基本知识，以及如何一般地阅读它（至少足以判断算法是否有效） .
他们应该模糊地知道触发器是什么，视图是什么，以及可以对数据库进行分区 . 他们不需要任何细节，但他们需要知道向DBA询问这些事情 .
他们当然应该知道不要干涉 生产环境 数据， 生产环境 代码或类似的东西，他们应该知道所有源代码都进入了VCS .
我无疑忘记了一些事情，但普通的开发人员不一定是DBA，前提是有一个真正的DBA .
基本索引
我没有设计数据库，只需编写一些查询，至少要了解它至关重要：
's indexed in your database and what'不是：
扫描类型之间的差异，它们的选择方式以及编写查询的方式可以影响该选择;
覆盖的概念（为什么你不应该只写
SELECT *）;聚簇索引和非聚簇索引之间的区别;
为什么更多/更大的指数不一定更好;
为什么要尝试避免在函数中包装过滤器列 .
设计师还应该了解常见的索引反模式，例如：
Access反模式（逐列索引每一列）
Catch-All反模式（所有或大多数列上的一个大型索引，显然是在错误的印象下创建的，它会加速涉及任何这些列的每个可能的查询） .
数据库索引的质量 - 以及您是否利用您编写的查询来利用它 - 占据了最重要的性能块 . 在SO和其他论坛上发布的10个问题中有9个抱怨性能不佳，总是由于索引不佳或不可搜索表达 .
标准化
总是让我感到沮丧的是看到有人在努力编写一个过于复杂的查询，而这个查询在规范化设计中会非常简单（“显示每个区域的总销售额”） .
如果您在一开始就明白这一点并进行相应的设计，那么您以后就会为自己省去很多痛苦 . 在规范化后，很容易对性能进行非规范化处理;规范化数据库从一开始就不是那么设计就不那么容易了 .
至少，您应该知道3NF是什么以及如何到达那里 . 对于大多数事务数据库，这是在使查询易于编写和保持良好性能之间的非常好的 balancer .
索引的工作原理
这可能不是最重要的，但肯定是最被低估的话题 .
索引的问题在于，SQL教程通常根本不提及它们，并且所有玩具示例都没有任何索引 .
更有经验的开发人员可以编写相当好的（和复杂的）SQL，而无需了解索引而不是“An index makes the query fast” .
那是因为SQL数据库执行 very good job 工作为黑盒子：
这非常适合检索正确的结果 . SQL的作者不需要知道系统在幕后做什么 - 直到一切都变得如此懒散......
这就是索引成为主题的时候 . 但这通常很晚才有人（某些公司？）已经遇到了真正的问题 .
这就是为什么我 believe indexing is the No. 1 topic not to forget when working with databases . 不幸的是，很容易忘记它 .
Disclaimer
这些论点来自我的免费电子书“Use The Index, Luke”的preface . 我花了很多时间来解释索引如何工作以及如何正确使用它们 .
我只是想指出一个观察 - 这似乎是大多数响应假设数据库可以与关系数据库互换 . 还有对象数据库，平面文件数据库 . 评估手头软件项目的需求非常重要 . 从程序员的角度来看，数据库决策可以延迟到以后 . 另一方面，数据建模可以在早期实现并取得很大成功 .
我认为数据建模是一个关键组件，是一个相对古老的概念，但它却被软件行业的许多人所遗忘 . 数据建模，尤其是概念建模，可以揭示系统的功能行为，并可以作为开发的路线图 .
另一方面，可以基于许多不同因素来确定所需的数据库类型，以包括环境，用户量和可用的本地硬件，例如硬盘空间 .
避免SQL injection以及如何保护您的数据库
每个开发人员都应该知道这是错误的：“分析数据库操作与分析代码完全不同 . ”
传统意义上有一个明显的Big-O . 当你执行
EXPLAIN PLAN（或等效的）时，你会看到算法 . 一些算法涉及嵌套循环，并且是 O （n ^ 2） . 其他算法涉及B树查找，并且是 O （n log n） .这非常非常严重 . 理解索引的重要性至关重要 . 它是理解速度归一化 - 非规范化权衡的关键 . 了解数据仓库为何使用未针对事务更新进行规范化的星型模式至关重要 .
如果您不清楚正在使用的算法，请执行以下操作 . 停止 . 解释查询执行计划 . 相应地调整指数 .
另外，推论：更多指数并不好 .
有时，专注于一个操作的索引会降低其他操作的速度 . 根据两个操作的比例，添加索引可能会产生良好的效果，没有整体影响，或者对整体性能有害 .
我想每个开发人员都应该理解 databases require a different paradigm .
在编写查询以获取数据时，需要基于集合的方法 . 许多具有交互背景的人都在为此而斗争 . 然而，当他们接受它时，他们可以获得更好的结果，即使解决方案可能不是首先在他们的迭代焦点思维中出现的那个 .
好问题 . 让我们看一下，首先没有人应该考虑查询一个没有完全理解连接的数据库 . 这就像驾驶汽车而不知道在哪里方向盘和制动器 . 您还需要知道数据类型以及如何选择最佳数据类型 .
开发人员应该理解的另一件事是在设计数据库时应该考虑三件事：
数据完整性 - 如果无法依赖数据，则基本上没有数据 - 这意味着不要在应用程序中放置所需的逻辑，因为许多其他源可能会触及数据库 . 数据完整性需要约束，外键和有时触发器 . 不要因为你不喜欢它们或者不想被理解而烦恼 .
性能 - 很难重构性能不佳的数据库，应该从一开始就考虑性能 . 有许多方法可以进行相同的查询，而且一些人知道几乎总是更快，不明白学习和使用这些方法是短视的 . 在设计查询或数据库结构之前，阅读一些关于性能调优的书
安全 - 这些数据是贵公司的生命线，它还经常包含可能被盗的个人信息 . 学习如何保护您的数据免受SQL注入攻击和欺诈以及身份盗用 .
查询数据库时，很容易得到错误的答案 . 确保您彻底了解您的数据模型 . 请记住，通常根据查询返回的数据做出实际决策 . 如果错了，就会做出错误的商业决策 . 你可以从错误的查询中杀死一家公司，或者让一个大客户失去信数据有意义，开发人员似乎常常忘记这一点 .
数据几乎永远不会消失，想想随着时间的推移存储数据而不是如何在今天获得数据 . 那个拥有十万条记录的数据库工作得很好，十年内可能不会那么好 . 应用程序很少会持续数据 . 这就是设计性能至关重要的原因之一 .
您的数据库可能需要应用程序不需要查看的字段 . 诸如复制的GUID，日期插入的字段之类的东西 . 您还可能需要存储更改历史记录以及更改历史记录以及何时能够从此仓库恢复错误更改 . 考虑如何在您向网站询问如何解决您忘记在更新中放置where子句并更新整个表的问题之前，打算如何执行此操作 .
永远不要在比 生产环境 版本更新的数据库版本中开发 . 从不，永远不会直接针对 生产环境 数据库进行开发 .
如果您没有数据库管理员，请确保有人正在进行备份并知道如何还原它们并已测试还原它们 .
数据库代码是代码，没有理由不将其保存在源代码管理中，就像代码的其余部分一样 .
进化数据库设计 . http://martinfowler.com/articles/evodb.html
这些敏捷方法使数据库更改过程易于管理，可预测且可测试 .
开发人员应该知道，在版本控制，持续集成和自动化测试方面，重构 生产环境 数据库需要什么 .
进化数据库设计过程具有管理方面，例如，在此代码库的所有数据库中的某个生命周期后，将删除一列 .
至少知道，存在数据库重构概念和方法 . http://www.agiledata.org/essays/databaseRefactoringCatalog.html
分类和过程描述也可以为这些重构实现工具 .
根据我对关系数据库的经验，每个开发人员都应该知道：
- The different data types ：
为正确的工作使用正确的类型将使您的数据库设计更加健壮，您的查询更快，生活更轻松 .
- Learn about 1xM and MxM ：
这是关系数据库的面包和黄油 . 您需要了解一对多和多对多关系，然后在适当时应用 .
- "K.I.S.S." principle applies to the DB as well ：
简洁总是最好的 . 如果您已经研究过数据库如何工作，您将避免不必要的复杂性，这将导致维护和速度问题 .
- Indices ：
如果你知道它们是什么，这还不够 . 您需要了解何时使用它们以及何时不使用它们 .
也：
布尔代数是你的朋友
图片：唐't store them on the DB. Don' t问为什么 .
使用SELECT测试DELETE