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

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

归一化

我总是很沮丧地看到有人努力编写一个过度复杂的查询，而这个查询用标准化的设计可以完全简单明了(“显示每个地区的总销售额。”)。

如果您在一开始就理解了这一点，并相应地进行设计，您将在以后为自己省去许多痛苦。在规范化之后，很容易对性能进行反规范化;要规范化一个从一开始就不是这样设计的数据库并不容易。

至少，您应该知道3NF是什么以及如何实现它。对于大多数事务性数据库，这是使查询易于编写和保持良好性能之间的一个很好的平衡。

索引的工作原理

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

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

即使更有经验的开发人员也可以编写相当好的(和复杂的)SQL，而不需要了解更多关于索引的知识，而只是“索引使查询更快”。

这是因为SQL数据库作为黑盒的工作做得非常好:

告诉我你需要什么(给我SQL)，我来处理。

这可以很好地检索正确的结果。SQL的作者不需要知道系统在幕后做什么——直到一切变得非常缓慢.....

这时索引就成了一个话题。但这通常很晚了，而且某些人(一些公司?)已经遇到了真正的问题。

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

免责声明

这些论点是从我的免费电子书“使用索引，卢克”的序言中借来的。我花了很多时间来解释索引是如何工作的，以及如何正确地使用它们。

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

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

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

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

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

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

第一列应该是其内容(即基数)变化最大的列。

这是为了帮助SQL Server在运行时如何使用索引创建有用的统计数据。

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

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.