我希望每个人，包括dba和开发人员/设计人员/架构师，都能更好地理解如何正确地对业务领域建模，以及如何将业务领域模型映射/转换为规范化的数据库逻辑模型、优化的物理模型和适当的面向对象类模型(每种模型由于各种原因(可能)不同)，并理解何时、为什么以及它们(或应该)如何彼此不同。

我希望每个人，包括dba和开发人员/设计人员/架构师，都能更好地理解如何正确地对业务领域建模，以及如何将业务领域模型映射/转换为规范化的数据库逻辑模型、优化的物理模型和适当的面向对象类模型(每种模型由于各种原因(可能)不同)，并理解何时、为什么以及它们(或应该)如何彼此不同。

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

—不同的数据类型:

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

—了解1xM和MxM:

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

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

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

——指数:

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

另外:

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

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

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

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

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

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

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

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

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

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

至于问题本身:

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

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