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

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


当前回答

进化数据库设计。http://martinfowler.com/articles/evodb.html

这些敏捷方法使数据库更改过程易于管理、可预测和可测试。

开发人员应该知道,在版本控制、持续集成和自动化测试方面重构生产数据库需要什么。

进化数据库设计过程具有管理方面的问题,例如,在此代码库的所有数据库中,某个列在某个生命周期后将被删除。

至少要知道数据库重构的概念和方法是存在的。 http://www.agiledata.org/essays/databaseRefactoringCatalog.html

分类和过程描述也使得为这些重构实现工具成为可能。

其他回答

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

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

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

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

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

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

好问题。以下是一些想法,排名不分先后:

Normalization, to at least the second normal form, is essential. Referential integrity is also essential, with proper cascading delete and update considerations. Good and proper use of check constraints. Let the database do as much work as possible. Don't scatter business logic in both the database and middle tier code. Pick one or the other, preferably in middle tier code. Decide on a consistent approach for primary keys and clustered keys. Don't over index. Choose your indexes wisely. Consistent table and column naming. Pick a standard and stick to it. Limit the number of columns in the database that will accept null values. Don't get carried away with triggers. They have their use but can complicate things in a hurry. Be careful with UDFs. They are great but can cause performance problems when you're not aware how often they might get called in a query. Get Celko's book on database design. The man is arrogant but knows his stuff.

三件事是一个神奇的数字:

数据库也需要版本控制。 游标很慢,您可能不需要它们。 触发器是邪恶的*

*几乎总是

基本的索引

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

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

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

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

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

不要依赖于SQL查询返回的行顺序。