关于数据库，开发人员应该知道的第一件事是:数据库是用来干什么的?不是它们如何工作，也不是如何构建它们，甚至不是如何编写代码来检索或更新数据库中的数据。但是它们有什么用呢?

不幸的是，这个问题的答案是一个移动的目标。在数据库的鼎盛时期，20世纪70年代到90年代初，数据库是为了共享数据。如果你正在使用一个数据库，而你没有共享数据，那么你要么是在参与一个学术项目，要么就是在浪费资源，包括你自己。建立一个数据库和驯服一个DBMS是如此巨大的任务，就数据被多次利用而言，回报必须与投资相匹配。

Over the last 15 years, databases have come to be used for storing the persistent data associated with just one application. Building a database for MySQL, or Access, or SQL Server has become so routine that databases have become almost a routine part of an ordinary application. Sometimes, that initial limited mission gets pushed upward by mission creep, as the real value of the data becomes apparent. Unfortunately, databases that were designed with a single purpose in mind often fail dramatically when they begin to be pushed into a role that's enterprise wide and mission critical.

关于数据库，开发人员需要了解的第二件事是整个以数据为中心的视图。以数据为中心的世界观不同于以流程为中心的世界观，这是大多数开发人员所学过的最不同的观点。与这个差距相比，结构化编程和面向对象编程之间的差距相对较小。

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

概念数据建模实际上是从以数据为中心的角度进行需求分析。

逻辑数据建模通常是将特定的数据模型应用于概念数据建模中发现的需求。关系模型的使用比任何其他特定模型都要多，开发人员肯定需要学习关系模型。为一个重要的需求设计一个强大且相关的关系模型并不是一项简单的任务。如果误解了关系模型，就无法构建良好的SQL表。

物理数据建模通常是特定于DBMS的，不需要了解太多细节，除非开发人员同时也是数据库构建者或DBA。开发人员需要了解的是，物理数据库设计可以在多大程度上与逻辑数据库设计分离，以及仅通过调整物理设计就可以在多大程度上生成高速数据库。

开发人员需要了解的下一件事是，虽然速度(性能)很重要，但其他衡量设计好坏的指标更重要，比如修改和扩展数据库范围的能力，或者编程的简单性。

最后，任何与数据库打交道的人都需要明白，数据的价值往往比捕获数据的系统更持久。

唷!

我只是想指出一个观察结果——似乎大多数的回答都假设数据库与关系数据库是可以互换的。还有对象数据库，平面文件数据库。评估当前软件项目的需求是很重要的。从程序员的角度来看，数据库决策可以推迟到以后。另一方面，数据建模可以在早期实现，并带来很大的成功。

我认为数据建模是一个关键组件，是一个相对较老的概念，但它已经被软件行业中的许多人遗忘了。数据建模，尤其是概念建模，可以揭示系统的功能行为，并可作为开发的路线图。

另一方面，所需的数据库类型可以根据许多不同的因素来确定，包括环境、用户数量和可用的本地硬件(如硬盘空间)。

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

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

在传统意义上有一个明确的Big-O。当你做一个EXPLAIN PLAN(或等效)时，你看到的是算法。有些算法涉及嵌套循环，并且是O(n ^ 2)。其他算法涉及到b树查找，并且是O(n log n)。

这是非常非常严重的。这是理解为什么索引很重要的关键。这对于理解速度-标准化-非标准化之间的权衡至关重要。这对于理解为什么数据仓库使用星型模式是非常重要的，而星型模式并没有对事务更新进行规范化。

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

同样，结论是:索引越多越好。

有时，专注于一个操作的索引会降低其他操作的速度。根据这两个操作的比例，添加一个索引可能有良好的效果，也可能没有整体影响，或者对整体性能不利。

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

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

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

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

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

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

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

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

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

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

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

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

每个c++极客在大学里都写过一个字符串类。每个图形狂人在大学里都写过一个光线追踪器。每个网络极客在大学里都写过交互式网站(通常在我们有“web框架”之前)。每个硬件书呆子(甚至软件书呆子)在大学里都做过CPU。大学里每个内科医生都解剖过一整具尸体，即使她今天只是给我量血压，告诉我胆固醇太高。为什么数据库会有所不同呢?

不幸的是，由于某种原因，他们今天看起来确实不一样了。人们希望。net程序员知道字符串在C语言中是如何工作的，但是RDBMS的内部结构不应该太关心你。

仅仅通过阅读，甚至从上到下都不可能达到同样的理解水平。但是，如果您从底层开始并理解每个部分，那么就相对容易找出数据库的细节。甚至是许多数据库极客似乎无法理解的事情，比如何时使用非关系数据库。

也许这有点严格，特别是如果你在大学里没有学习计算机科学。我会把它调低一些:你今天完全可以从头开始写一个。我不关心你是否知道PostgreSQL查询优化器的工作原理，但如果你知道足够多的知识自己编写一个，它可能不会与他们所做的有太大的不同。你知道，写一个基本的公式并不难。