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

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

非常好的问题。让我们看看，首先，没有完全理解连接的人不应该考虑查询数据库。这就像开车时不知道方向盘和刹车在哪里一样。您还需要了解数据类型以及如何选择最佳数据类型。

开发人员应该了解的另一件事是，在设计数据库时，你应该记住三件事:

Data integrity - if the data can't be relied on you essentially have no data - this means do not put required logic in the application as many other sources may touch the database. Constraints, foreign keys and sometimes triggers are necessary to data integrity. Don't fail to use them because you don't like them or don't want to be bothered to understand them. Performance - it is very hard to refactor a poorly performing database and performance should be considered from the start. There are many ways to do the same query and some are known to be faster almost always, it is short-sighted not to learn and use these ways. Read some books on performance tuning before designing queries or database structures. Security - this data is the life-blood of your company, it also frequently contains personal information that can be stolen. Learn to protect your data from SQL injection attacks and fraud and identity theft.

在查询数据库时，很容易得到错误的答案。确保完全理解数据模型。请记住，实际决策通常是基于查询返回的数据做出的。当它是错误的，就会做出错误的商业决策。你可能会因为糟糕的询问而杀死一家公司，或者失去一个大客户。数据是有意义的，但开发者往往忘记了这一点。

数据几乎永远不会消失，考虑的是随着时间的推移存储数据，而不是今天如何获取数据。数据库在拥有10万条记录时运行良好，十年后可能就不那么好了。应用程序很少能像数据一样持久。这就是为什么性能设计如此重要的原因之一。

您的数据库可能需要应用程序不需要看到的字段。比如用于复制的guid，插入的日期字段。等。您还可能需要存储更改的历史，以及谁在什么时候做了更改，并能够从这个存储库中恢复坏的更改。在向网站询问如何修复忘记在更新中添加where子句并更新整个表的问题之前，请考虑一下您打算如何做到这一点。

永远不要在比生产版本更新的数据库版本中进行开发。永远、永远、永远不要直接针对生产数据库进行开发。

如果没有数据库管理员，请确保有人正在进行备份，并且知道如何恢复备份，并且已经测试过如何恢复备份。

数据库代码就是代码，没有理由不把它像其他代码一样放在源代码控制中。

首先，开发人员需要了解一些关于数据库的知识。它们不仅仅是输入SQL并得到结果集的神奇设备，而是具有自己的逻辑和癖好的非常复杂的软件。

其次，针对不同的目的有不同的数据库设置。如果有可用的数据仓库，则不希望开发人员从联机事务数据库生成历史报告。

第三，开发人员需要了解基本的SQL，包括连接。

除此之外，它还取决于开发人员参与的程度。我曾经工作过，我是开发人员，实际上是DBA, DBA只是在走道的另一边，而DBA则在各自的领域。(我不喜欢第三个。)假设开发人员参与了数据库设计:

他们需要了解基本的标准化，至少是前三种标准形式。除此之外，请找一个DBA。对于那些有过美国法庭(以及随便看的电视节目)经验的人来说，有一句便于记忆的话:“依靠钥匙，全部的钥匙，除了钥匙别无其他，帮你一把，科德。”

他们需要了解索引，我的意思是他们应该知道他们需要什么索引，以及它们可能如何影响性能。这意味着不要使用无用的索引，但不要害怕添加它们来辅助查询。任何进一步的工作(如余额)都应该留给DBA。

他们需要理解对数据完整性的需求，并能够指出他们在哪里验证数据，以及如果发现问题他们正在做什么。这并不一定要在数据库中(在数据库中很难向用户发出有意义的错误消息)，但必须在某个地方。

他们应该具备如何制定计划的基本知识，以及如何大体阅读计划(至少足以判断算法是否有效)。

他们应该模糊地知道什么是触发器，什么是视图，以及可以对数据库进行分区。他们不需要任何细节，但他们需要知道如何向DBA询问这些事情。

他们当然应该知道不要干涉生产数据，或生产代码，或类似的东西，他们应该知道所有的源代码都进入VCS。

毫无疑问，我忘记了一些事情，但是一般的开发人员不需要是DBA，前提是手头有一个真正的DBA。

不要依赖于SQL查询返回的行顺序。

阻抗失配问题，并了解常见缺陷或orm。

归一化

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

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

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