不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
当前回答
我希望每个人,包括dba和开发人员/设计人员/架构师,都能更好地理解如何正确地对业务领域建模,以及如何将业务领域模型映射/转换为规范化的数据库逻辑模型、优化的物理模型和适当的面向对象类模型(每种模型由于各种原因(可能)不同),并理解何时、为什么以及它们(或应该)如何彼此不同。
其他回答
我希望每个人,包括dba和开发人员/设计人员/架构师,都能更好地理解如何正确地对业务领域建模,以及如何将业务领域模型映射/转换为规范化的数据库逻辑模型、优化的物理模型和适当的面向对象类模型(每种模型由于各种原因(可能)不同),并理解何时、为什么以及它们(或应该)如何彼此不同。
我会说有很强的SQL基础技能。到目前为止,我见过许多对数据库了解不多的开发人员,但总是询问如何制定一个相当简单的查询的技巧。查询并不总是那么容易和简单。在查询规范化良好的数据库时,必须使用多个连接(内部连接、左连接等)。
永远不要以错误的文本编码插入数据。
一旦您的数据库受到多种编码的污染,您所能做的最好的事情就是应用启发式和手工劳动的某种组合。
索引的工作原理
这可能不是最重要的,但肯定是最被低估的话题。
索引的问题在于SQL教程通常根本不会提到它们,而且所有的玩具示例都可以在没有索引的情况下工作。
即使更有经验的开发人员也可以编写相当好的(和复杂的)SQL,而不需要了解更多关于索引的知识,而只是“索引使查询更快”。
这是因为SQL数据库作为黑盒的工作做得非常好:
告诉我你需要什么(给我SQL),我来处理。
这可以很好地检索正确的结果。SQL的作者不需要知道系统在幕后做什么——直到一切变得非常缓慢.....
这时索引就成了一个话题。但这通常很晚了,而且某些人(一些公司?)已经遇到了真正的问题。
这就是为什么我认为索引是在使用数据库时不能忘记的首要主题。不幸的是,它很容易忘记。
免责声明
这些论点是从我的免费电子书“使用索引,卢克”的序言中借来的。我花了很多时间来解释索引是如何工作的,以及如何正确地使用它们。
首先,开发人员需要了解一些关于数据库的知识。它们不仅仅是输入SQL并得到结果集的神奇设备,而是具有自己的逻辑和癖好的非常复杂的软件。
其次,针对不同的目的有不同的数据库设置。如果有可用的数据仓库,则不希望开发人员从联机事务数据库生成历史报告。
第三,开发人员需要了解基本的SQL,包括连接。
除此之外,它还取决于开发人员参与的程度。我曾经工作过,我是开发人员,实际上是DBA, DBA只是在走道的另一边,而DBA则在各自的领域。(我不喜欢第三个。)假设开发人员参与了数据库设计:
他们需要了解基本的标准化,至少是前三种标准形式。除此之外,请找一个DBA。对于那些有过美国法庭(以及随便看的电视节目)经验的人来说,有一句便于记忆的话:“依靠钥匙,全部的钥匙,除了钥匙别无其他,帮你一把,科德。”
他们需要了解索引,我的意思是他们应该知道他们需要什么索引,以及它们可能如何影响性能。这意味着不要使用无用的索引,但不要害怕添加它们来辅助查询。任何进一步的工作(如余额)都应该留给DBA。
他们需要理解对数据完整性的需求,并能够指出他们在哪里验证数据,以及如果发现问题他们正在做什么。这并不一定要在数据库中(在数据库中很难向用户发出有意义的错误消息),但必须在某个地方。
他们应该具备如何制定计划的基本知识,以及如何大体阅读计划(至少足以判断算法是否有效)。
他们应该模糊地知道什么是触发器,什么是视图,以及可以对数据库进行分区。他们不需要任何细节,但他们需要知道如何向DBA询问这些事情。
他们当然应该知道不要干涉生产数据,或生产代码,或类似的东西,他们应该知道所有的源代码都进入VCS。
毫无疑问,我忘记了一些事情,但是一般的开发人员不需要是DBA,前提是手头有一个真正的DBA。