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

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

好问题。以下是一些想法，排名不分先后:

Normalization, to at least the second normal form, is essential. Referential integrity is also essential, with proper cascading delete and update considerations. Good and proper use of check constraints. Let the database do as much work as possible. Don't scatter business logic in both the database and middle tier code. Pick one or the other, preferably in middle tier code. Decide on a consistent approach for primary keys and clustered keys. Don't over index. Choose your indexes wisely. Consistent table and column naming. Pick a standard and stick to it. Limit the number of columns in the database that will accept null values. Don't get carried away with triggers. They have their use but can complicate things in a hurry. Be careful with UDFs. They are great but can cause performance problems when you're not aware how often they might get called in a query. Get Celko's book on database design. The man is arrogant but knows his stuff.

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

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

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

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

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

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

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

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

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

根据我使用关系数据库的经验，每个开发人员都应该知道:

—不同的数据类型:

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

—了解1xM和MxM:

这是关系数据库的基本功能。您需要理解一对多和多对多关系，并在适当的时候应用它们。

“K.I.S.S.”原则也适用于DB

简单总是最好的。如果你已经学习了数据库是如何工作的，你将避免不必要的复杂性，这将导致维护和速度问题。

——指数:

光知道它们是什么是不够的。你需要知道什么时候使用，什么时候不使用。

另外:

布尔代数是你的朋友 图像:不要将它们存储在DB上。不要问为什么。 用SELECT测试DELETE

我想这里已经介绍了很多技术细节，我不想再补充了。我想说的一件事是，社交比技术更重要，作为应用程序开发人员，不要陷入“DBA知道最好的”的陷阱。

如果您在查询方面有性能问题，也要解决这个问题。自己进行研究，并要求dba解释发生了什么，以及他们的解决方案是如何解决问题的。

在你做了研究之后，也要提出你自己的建议。也就是说，我试图找到解决问题的合作解决方案，而不是将数据库问题留给dba。