索引的工作原理

这可能不是最重要的，但肯定是最被低估的话题。

索引的问题在于SQL教程通常根本不会提到它们，而且所有的玩具示例都可以在没有索引的情况下工作。

即使更有经验的开发人员也可以编写相当好的(和复杂的)SQL，而不需要了解更多关于索引的知识，而只是“索引使查询更快”。

这是因为SQL数据库作为黑盒的工作做得非常好:

告诉我你需要什么(给我SQL)，我来处理。

这可以很好地检索正确的结果。SQL的作者不需要知道系统在幕后做什么——直到一切变得非常缓慢.....

这时索引就成了一个话题。但这通常很晚了，而且某些人(一些公司?)已经遇到了真正的问题。

这就是为什么我认为索引是在使用数据库时不能忘记的首要主题。不幸的是，它很容易忘记。

免责声明

这些论点是从我的免费电子书“使用索引，卢克”的序言中借来的。我花了很多时间来解释索引是如何工作的，以及如何正确地使用它们。

阻抗失配问题，并了解常见缺陷或orm。

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

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

*几乎总是

我认为每个开发人员都应该理解数据库需要不同的范例。

在编写查询以获取数据时，需要一种基于集的方法。许多具有交互背景的人对此感到困惑。然而，当他们接受它时，他们可以获得更好的结果，即使解决方案可能不是第一次出现在他们以迭代为中心的思想中的解决方案。

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

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

关于数据库，开发人员应该知道的第一件事是:数据库是用来干什么的?不是它们如何工作，也不是如何构建它们，甚至不是如何编写代码来检索或更新数据库中的数据。但是它们有什么用呢?

不幸的是，这个问题的答案是一个移动的目标。在数据库的鼎盛时期，20世纪70年代到90年代初，数据库是为了共享数据。如果你正在使用一个数据库，而你没有共享数据，那么你要么是在参与一个学术项目，要么就是在浪费资源，包括你自己。建立一个数据库和驯服一个DBMS是如此巨大的任务，就数据被多次利用而言，回报必须与投资相匹配。

Over the last 15 years, databases have come to be used for storing the persistent data associated with just one application. Building a database for MySQL, or Access, or SQL Server has become so routine that databases have become almost a routine part of an ordinary application. Sometimes, that initial limited mission gets pushed upward by mission creep, as the real value of the data becomes apparent. Unfortunately, databases that were designed with a single purpose in mind often fail dramatically when they begin to be pushed into a role that's enterprise wide and mission critical.

关于数据库，开发人员需要了解的第二件事是整个以数据为中心的视图。以数据为中心的世界观不同于以流程为中心的世界观，这是大多数开发人员所学过的最不同的观点。与这个差距相比，结构化编程和面向对象编程之间的差距相对较小。

开发人员需要学习的第三件事是数据建模，包括概念数据建模、逻辑数据建模和物理数据建模。

概念数据建模实际上是从以数据为中心的角度进行需求分析。

逻辑数据建模通常是将特定的数据模型应用于概念数据建模中发现的需求。关系模型的使用比任何其他特定模型都要多，开发人员肯定需要学习关系模型。为一个重要的需求设计一个强大且相关的关系模型并不是一项简单的任务。如果误解了关系模型，就无法构建良好的SQL表。

物理数据建模通常是特定于DBMS的，不需要了解太多细节，除非开发人员同时也是数据库构建者或DBA。开发人员需要了解的是，物理数据库设计可以在多大程度上与逻辑数据库设计分离，以及仅通过调整物理设计就可以在多大程度上生成高速数据库。

开发人员需要了解的下一件事是，虽然速度(性能)很重要，但其他衡量设计好坏的指标更重要，比如修改和扩展数据库范围的能力，或者编程的简单性。

最后，任何与数据库打交道的人都需要明白，数据的价值往往比捕获数据的系统更持久。

唷!