不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。

关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?


当前回答

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

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

其他回答

每个开发人员都应该知道这是错误的:“分析数据库操作与分析代码完全不同。”

在传统意义上有一个明确的Big-O。当你做一个EXPLAIN PLAN(或等效)时,你看到的是算法。有些算法涉及嵌套循环,并且是O(n ^ 2)。其他算法涉及到b树查找,并且是O(n log n)。

这是非常非常严重的。这是理解为什么索引很重要的关键。这对于理解速度-标准化-非标准化之间的权衡至关重要。这对于理解为什么数据仓库使用星型模式是非常重要的,而星型模式并没有对事务更新进行规范化。

如果您不清楚所使用的算法,请执行以下操作。停止。解释查询执行计划。相应调整指标。

同样,结论是:索引越多越好。

有时,专注于一个操作的索引会降低其他操作的速度。根据这两个操作的比例,添加一个索引可能有良好的效果,也可能没有整体影响,或者对整体性能不利。

基本的索引

当看到一个表或整个数据库没有索引,或者索引是任意的/无用的时,我总是感到震惊。即使你不是在设计数据库,只是需要编写一些查询,至少理解以下内容仍然是至关重要的:

数据库中索引了什么,没有索引什么: 扫描类型之间的差异,它们是如何选择的,以及您编写查询的方式如何影响这种选择; 覆盖率的概念(为什么你不应该只写SELECT *); 聚类索引和非聚类索引之间的区别; 为什么更多/更大的指数不一定更好; 为什么应该尽量避免在函数中包装筛选器列。

设计人员还应该注意常见的索引反模式,例如:

Access反模式(逐个索引每一列) Catch-All反模式(在所有或大多数列上建立一个大型索引,显然是在错误的印象中创建的,认为它会加速涉及这些列的所有可以想象的查询)。

数据库索引的质量——以及您在编写查询时是否利用了它——是迄今为止最重要的性能部分。在SO和其他论坛上发布的抱怨性能不佳的问题中,10个问题中有9个总是被证明是由于索引不好或表达式不sargable。

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

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

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

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

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

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

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

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

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