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

—不同的数据类型:

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

—了解1xM和MxM:

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

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

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

——指数:

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

另外:

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

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

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

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

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

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

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

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

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.

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

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

关于以下对Walter M。的回答:

“写得很好!历史视角对于当时没有做数据库工作的人(比如我)来说非常有用。”

历史观点在某种意义上是绝对重要的。“忘记历史的人，注定要重蹈覆辙。”XML重复着过去的层次错误，图形数据库重复着过去的网络错误，OO系统迫使用户使用层次模型，而每个人即使只有十分之一的大脑都应该知道层次模型不适合真实世界的通用表示，等等，等等。

至于问题本身:

每个数据库开发人员都应该知道“关系型”不等于“SQL”。然后他们就会明白为什么他们会被DBMS供应商如此失望，为什么他们应该告诉同样的供应商想出更好的东西(例如真正的关系型DBMS)，如果他们想继续从他们的客户那里为这些蹩脚的软件吸走大量的钱)。

每个数据库开发人员都应该了解关系代数的所有知识。这样，就不会再有开发者在Stack Overflow网站上发布“我不知道如何做我的工作，希望别人帮我做”这样的愚蠢问题了。

永远不要以错误的文本编码插入数据。

一旦您的数据库受到多种编码的污染，您所能做的最好的事情就是应用启发式和手工劳动的某种组合。

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

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