将非正规化视为一个可能的天使，而不是魔鬼，并将NoSQL数据库视为关系数据库的替代方案。

此外，我认为实体-关系模型是每个开发人员必须知道的，即使你不设计数据库。它将让您彻底理解数据库的所有内容。

除了他们使用的语法和概念选项(例如连接、触发器和存储过程)之外，对于每个使用数据库的开发人员来说，有一件事是至关重要的:

了解您的引擎将如何执行您正在编写的查询。

我认为这很重要的原因仅仅是生产的稳定性。您应该知道您的代码是如何执行的，这样您就不会在等待一个长函数完成时停止线程中的所有执行，那么为什么您不想知道您的查询将如何影响数据库、程序甚至服务器呢?

This is actually something that has hit my R&D team more times than missing semicolons or the like. The presumtion is the query will execute quickly because it does on their development system with only a few thousand rows in the tables. Even if the production database is the same size, it is more than likely going to be used a lot more, and thus suffer from other constraints like multiple users accessing it at the same time, or something going wrong with another query elsewhere, thus delaying the result of this query.

即使是像连接如何影响查询性能这样简单的事情，在生产中也是非常宝贵的。许多数据库引擎的许多特性在概念上让事情变得更简单，但如果没有考虑清楚，可能会在性能上带来问题。

了解数据库引擎的执行过程，并为之制定计划。

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

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

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

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

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

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

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

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

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

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

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

了解用于数据库编程的工具!!

我浪费了很多时间试图理解为什么我的代码神秘地失败了。

例如，如果您正在使用。net，您需要知道如何正确使用System.Data.SqlClient名称空间中的对象。您需要知道如何管理SqlConnection对象，以确保它们被打开、关闭，并在必要时正确地处理。

你需要知道，当你使用SqlDataReader时，有必要将它与你的SqlConnection分开关闭。您需要了解如何在适当的时候保持连接打开，以及如何最小化对数据库的访问次数(因为它们在计算时间方面相对昂贵)。

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

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.