不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
当前回答
根据我使用关系数据库的经验,每个开发人员都应该知道:
—不同的数据类型:
为正确的工作使用正确的类型将使您的DB设计更健壮,查询更快,生活更轻松。
—了解1xM和MxM:
这是关系数据库的基本功能。您需要理解一对多和多对多关系,并在适当的时候应用它们。
“K.I.S.S.”原则也适用于DB
简单总是最好的。如果你已经学习了数据库是如何工作的,你将避免不必要的复杂性,这将导致维护和速度问题。
——指数:
光知道它们是什么是不够的。你需要知道什么时候使用,什么时候不使用。
另外:
布尔代数是你的朋友 图像:不要将它们存储在DB上。不要问为什么。 用SELECT测试DELETE
其他回答
根据我使用关系数据库的经验,每个开发人员都应该知道:
—不同的数据类型:
为正确的工作使用正确的类型将使您的DB设计更健壮,查询更快,生活更轻松。
—了解1xM和MxM:
这是关系数据库的基本功能。您需要理解一对多和多对多关系,并在适当的时候应用它们。
“K.I.S.S.”原则也适用于DB
简单总是最好的。如果你已经学习了数据库是如何工作的,你将避免不必要的复杂性,这将导致维护和速度问题。
——指数:
光知道它们是什么是不够的。你需要知道什么时候使用,什么时候不使用。
另外:
布尔代数是你的朋友 图像:不要将它们存储在DB上。不要问为什么。 用SELECT测试DELETE
我认为每个开发人员都应该理解数据库需要不同的范例。
在编写查询以获取数据时,需要一种基于集的方法。许多具有交互背景的人对此感到困惑。然而,当他们接受它时,他们可以获得更好的结果,即使解决方案可能不是第一次出现在他们以迭代为中心的思想中的解决方案。
基本的索引
当看到一个表或整个数据库没有索引,或者索引是任意的/无用的时,我总是感到震惊。即使你不是在设计数据库,只是需要编写一些查询,至少理解以下内容仍然是至关重要的:
数据库中索引了什么,没有索引什么: 扫描类型之间的差异,它们是如何选择的,以及您编写查询的方式如何影响这种选择; 覆盖率的概念(为什么你不应该只写SELECT *); 聚类索引和非聚类索引之间的区别; 为什么更多/更大的指数不一定更好; 为什么应该尽量避免在函数中包装筛选器列。
设计人员还应该注意常见的索引反模式,例如:
Access反模式(逐个索引每一列) Catch-All反模式(在所有或大多数列上建立一个大型索引,显然是在错误的印象中创建的,认为它会加速涉及这些列的所有可以想象的查询)。
数据库索引的质量——以及您在编写查询时是否利用了它——是迄今为止最重要的性能部分。在SO和其他论坛上发布的抱怨性能不佳的问题中,10个问题中有9个总是被证明是由于索引不好或表达式不sargable。
索引的工作原理
这可能不是最重要的,但肯定是最被低估的话题。
索引的问题在于SQL教程通常根本不会提到它们,而且所有的玩具示例都可以在没有索引的情况下工作。
即使更有经验的开发人员也可以编写相当好的(和复杂的)SQL,而不需要了解更多关于索引的知识,而只是“索引使查询更快”。
这是因为SQL数据库作为黑盒的工作做得非常好:
告诉我你需要什么(给我SQL),我来处理。
这可以很好地检索正确的结果。SQL的作者不需要知道系统在幕后做什么——直到一切变得非常缓慢.....
这时索引就成了一个话题。但这通常很晚了,而且某些人(一些公司?)已经遇到了真正的问题。
这就是为什么我认为索引是在使用数据库时不能忘记的首要主题。不幸的是,它很容易忘记。
免责声明
这些论点是从我的免费电子书“使用索引,卢克”的序言中借来的。我花了很多时间来解释索引是如何工作的,以及如何正确地使用它们。
阻抗失配问题,并了解常见缺陷或orm。