我想这里已经介绍了很多技术细节，我不想再补充了。我想说的一件事是，社交比技术更重要，作为应用程序开发人员，不要陷入“DBA知道最好的”的陷阱。

如果您在查询方面有性能问题，也要解决这个问题。自己进行研究，并要求dba解释发生了什么，以及他们的解决方案是如何解决问题的。

在你做了研究之后，也要提出你自己的建议。也就是说，我试图找到解决问题的合作解决方案，而不是将数据库问题留给dba。

我会说有很强的SQL基础技能。到目前为止，我见过许多对数据库了解不多的开发人员，但总是询问如何制定一个相当简单的查询的技巧。查询并不总是那么容易和简单。在查询规范化良好的数据库时，必须使用多个连接(内部连接、左连接等)。

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

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

我只是想指出一个观察结果——似乎大多数的回答都假设数据库与关系数据库是可以互换的。还有对象数据库，平面文件数据库。评估当前软件项目的需求是很重要的。从程序员的角度来看，数据库决策可以推迟到以后。另一方面，数据建模可以在早期实现，并带来很大的成功。

我认为数据建模是一个关键组件，是一个相对较老的概念，但它已经被软件行业中的许多人遗忘了。数据建模，尤其是概念建模，可以揭示系统的功能行为，并可作为开发的路线图。

另一方面，所需的数据库类型可以根据许多不同的因素来确定，包括环境、用户数量和可用的本地硬件(如硬盘空间)。

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

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

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

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

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

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

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