三件事是一个神奇的数字:

数据库也需要版本控制。 游标很慢，您可能不需要它们。 触发器是邪恶的*

*几乎总是

归一化

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

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

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

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

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

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

三件事是一个神奇的数字:

数据库也需要版本控制。 游标很慢，您可能不需要它们。 触发器是邪恶的*

*几乎总是

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

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

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

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

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

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

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

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.