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

在编写查询以获取数据时，需要一种基于集的方法。许多具有交互背景的人对此感到困惑。然而，当他们接受它时，他们可以获得更好的结果，即使解决方案可能不是第一次出现在他们以迭代为中心的思想中的解决方案。

基本的索引

当看到一个表或整个数据库没有索引，或者索引是任意的/无用的时，我总是感到震惊。即使你不是在设计数据库，只是需要编写一些查询，至少理解以下内容仍然是至关重要的:

数据库中索引了什么，没有索引什么: 扫描类型之间的差异，它们是如何选择的，以及您编写查询的方式如何影响这种选择; 覆盖率的概念(为什么你不应该只写SELECT *); 聚类索引和非聚类索引之间的区别; 为什么更多/更大的指数不一定更好; 为什么应该尽量避免在函数中包装筛选器列。

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

Access反模式(逐个索引每一列) Catch-All反模式(在所有或大多数列上建立一个大型索引，显然是在错误的印象中创建的，认为它会加速涉及这些列的所有可以想象的查询)。

数据库索引的质量——以及您在编写查询时是否利用了它——是迄今为止最重要的性能部分。在SO和其他论坛上发布的抱怨性能不佳的问题中，10个问题中有9个总是被证明是由于索引不好或表达式不sargable。

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

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

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

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

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

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

在编写查询以获取数据时，需要一种基于集的方法。许多具有交互背景的人对此感到困惑。然而，当他们接受它时，他们可以获得更好的结果，即使解决方案可能不是第一次出现在他们以迭代为中心的思想中的解决方案。

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

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

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

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

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

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

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

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

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

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

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