不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
当前回答
我认为每个开发人员都应该理解数据库需要不同的范例。
在编写查询以获取数据时,需要一种基于集的方法。许多具有交互背景的人对此感到困惑。然而,当他们接受它时,他们可以获得更好的结果,即使解决方案可能不是第一次出现在他们以迭代为中心的思想中的解决方案。
其他回答
每个开发人员都应该知道这是错误的:“分析数据库操作与分析代码完全不同。”
在传统意义上有一个明确的Big-O。当你做一个EXPLAIN PLAN(或等效)时,你看到的是算法。有些算法涉及嵌套循环,并且是O(n ^ 2)。其他算法涉及到b树查找,并且是O(n log n)。
这是非常非常严重的。这是理解为什么索引很重要的关键。这对于理解速度-标准化-非标准化之间的权衡至关重要。这对于理解为什么数据仓库使用星型模式是非常重要的,而星型模式并没有对事务更新进行规范化。
如果您不清楚所使用的算法,请执行以下操作。停止。解释查询执行计划。相应调整指标。
同样,结论是:索引越多越好。
有时,专注于一个操作的索引会降低其他操作的速度。根据这两个操作的比例,添加一个索引可能有良好的效果,也可能没有整体影响,或者对整体性能不利。
首先,开发人员需要了解一些关于数据库的知识。它们不仅仅是输入SQL并得到结果集的神奇设备,而是具有自己的逻辑和癖好的非常复杂的软件。
其次,针对不同的目的有不同的数据库设置。如果有可用的数据仓库,则不希望开发人员从联机事务数据库生成历史报告。
第三,开发人员需要了解基本的SQL,包括连接。
除此之外,它还取决于开发人员参与的程度。我曾经工作过,我是开发人员,实际上是DBA, DBA只是在走道的另一边,而DBA则在各自的领域。(我不喜欢第三个。)假设开发人员参与了数据库设计:
他们需要了解基本的标准化,至少是前三种标准形式。除此之外,请找一个DBA。对于那些有过美国法庭(以及随便看的电视节目)经验的人来说,有一句便于记忆的话:“依靠钥匙,全部的钥匙,除了钥匙别无其他,帮你一把,科德。”
他们需要了解索引,我的意思是他们应该知道他们需要什么索引,以及它们可能如何影响性能。这意味着不要使用无用的索引,但不要害怕添加它们来辅助查询。任何进一步的工作(如余额)都应该留给DBA。
他们需要理解对数据完整性的需求,并能够指出他们在哪里验证数据,以及如果发现问题他们正在做什么。这并不一定要在数据库中(在数据库中很难向用户发出有意义的错误消息),但必须在某个地方。
他们应该具备如何制定计划的基本知识,以及如何大体阅读计划(至少足以判断算法是否有效)。
他们应该模糊地知道什么是触发器,什么是视图,以及可以对数据库进行分区。他们不需要任何细节,但他们需要知道如何向DBA询问这些事情。
他们当然应该知道不要干涉生产数据,或生产代码,或类似的东西,他们应该知道所有的源代码都进入VCS。
毫无疑问,我忘记了一些事情,但是一般的开发人员不需要是DBA,前提是手头有一个真正的DBA。
避免SQL注入以及如何保护您的数据库
我只是想指出一个观察结果——似乎大多数的回答都假设数据库与关系数据库是可以互换的。还有对象数据库,平面文件数据库。评估当前软件项目的需求是很重要的。从程序员的角度来看,数据库决策可以推迟到以后。另一方面,数据建模可以在早期实现,并带来很大的成功。
我认为数据建模是一个关键组件,是一个相对较老的概念,但它已经被软件行业中的许多人遗忘了。数据建模,尤其是概念建模,可以揭示系统的功能行为,并可作为开发的路线图。
另一方面,所需的数据库类型可以根据许多不同的因素来确定,包括环境、用户数量和可用的本地硬件(如硬盘空间)。
三件事是一个神奇的数字:
数据库也需要版本控制。 游标很慢,您可能不需要它们。 触发器是邪恶的*
*几乎总是