不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
当前回答
每个开发人员都应该知道这是错误的:“分析数据库操作与分析代码完全不同。”
在传统意义上有一个明确的Big-O。当你做一个EXPLAIN PLAN(或等效)时,你看到的是算法。有些算法涉及嵌套循环,并且是O(n ^ 2)。其他算法涉及到b树查找,并且是O(n log n)。
这是非常非常严重的。这是理解为什么索引很重要的关键。这对于理解速度-标准化-非标准化之间的权衡至关重要。这对于理解为什么数据仓库使用星型模式是非常重要的,而星型模式并没有对事务更新进行规范化。
如果您不清楚所使用的算法,请执行以下操作。停止。解释查询执行计划。相应调整指标。
同样,结论是:索引越多越好。
有时,专注于一个操作的索引会降低其他操作的速度。根据这两个操作的比例,添加一个索引可能有良好的效果,也可能没有整体影响,或者对整体性能不利。
其他回答
我希望每个人,包括dba和开发人员/设计人员/架构师,都能更好地理解如何正确地对业务领域建模,以及如何将业务领域模型映射/转换为规范化的数据库逻辑模型、优化的物理模型和适当的面向对象类模型(每种模型由于各种原因(可能)不同),并理解何时、为什么以及它们(或应该)如何彼此不同。
我只是想指出一个观察结果——似乎大多数的回答都假设数据库与关系数据库是可以互换的。还有对象数据库,平面文件数据库。评估当前软件项目的需求是很重要的。从程序员的角度来看,数据库决策可以推迟到以后。另一方面,数据建模可以在早期实现,并带来很大的成功。
我认为数据建模是一个关键组件,是一个相对较老的概念,但它已经被软件行业中的许多人遗忘了。数据建模,尤其是概念建模,可以揭示系统的功能行为,并可作为开发的路线图。
另一方面,所需的数据库类型可以根据许多不同的因素来确定,包括环境、用户数量和可用的本地硬件(如硬盘空间)。
RDBMS兼容性
查看是否需要在多个RDBMS中运行应用程序。如有,可能需要:
避免RDBMS SQL扩展 消除触发器和存储过程 遵循严格的SQL标准 转换字段数据类型 更改事务隔离级别
否则,这些问题应该分开处理,并开发应用程序的不同版本(或配置)。
对于一些项目,面向对象模型更好。
对于其他项目,关系模型更好。
避免SQL注入以及如何保护您的数据库