不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
不管我们喜欢与否,我们开发人员中的许多人(如果不是大多数的话)都经常使用数据库,或者有一天可能不得不使用数据库。考虑到大量的误用和滥用,以及每天出现的大量与数据库相关的问题,公平地说,有一些概念是开发人员应该知道的——即使他们今天不设计或使用数据库。
关于数据库,开发人员和其他软件专业人员应该知道的一个重要概念是什么?
当前回答
对于一个经常使用数据库(每天或几乎每天编写/维护查询)的中间派专业开发人员,我认为期望应该与任何其他领域相同:你在大学里写过一个。
每个c++极客在大学里都写过一个字符串类。每个图形狂人在大学里都写过一个光线追踪器。每个网络极客在大学里都写过交互式网站(通常在我们有“web框架”之前)。每个硬件书呆子(甚至软件书呆子)在大学里都做过CPU。大学里每个内科医生都解剖过一整具尸体,即使她今天只是给我量血压,告诉我胆固醇太高。为什么数据库会有所不同呢?
不幸的是,由于某种原因,他们今天看起来确实不一样了。人们希望。net程序员知道字符串在C语言中是如何工作的,但是RDBMS的内部结构不应该太关心你。
仅仅通过阅读,甚至从上到下都不可能达到同样的理解水平。但是,如果您从底层开始并理解每个部分,那么就相对容易找出数据库的细节。甚至是许多数据库极客似乎无法理解的事情,比如何时使用非关系数据库。
也许这有点严格,特别是如果你在大学里没有学习计算机科学。我会把它调低一些:你今天完全可以从头开始写一个。我不关心你是否知道PostgreSQL查询优化器的工作原理,但如果你知道足够多的知识自己编写一个,它可能不会与他们所做的有太大的不同。你知道,写一个基本的公式并不难。
其他回答
根据我使用关系数据库的经验,每个开发人员都应该知道:
—不同的数据类型:
为正确的工作使用正确的类型将使您的DB设计更健壮,查询更快,生活更轻松。
—了解1xM和MxM:
这是关系数据库的基本功能。您需要理解一对多和多对多关系,并在适当的时候应用它们。
“K.I.S.S.”原则也适用于DB
简单总是最好的。如果你已经学习了数据库是如何工作的,你将避免不必要的复杂性,这将导致维护和速度问题。
——指数:
光知道它们是什么是不够的。你需要知道什么时候使用,什么时候不使用。
另外:
布尔代数是你的朋友 图像:不要将它们存储在DB上。不要问为什么。 用SELECT测试DELETE
除了他们使用的语法和概念选项(例如连接、触发器和存储过程)之外,对于每个使用数据库的开发人员来说,有一件事是至关重要的:
了解您的引擎将如何执行您正在编写的查询。
我认为这很重要的原因仅仅是生产的稳定性。您应该知道您的代码是如何执行的,这样您就不会在等待一个长函数完成时停止线程中的所有执行,那么为什么您不想知道您的查询将如何影响数据库、程序甚至服务器呢?
This is actually something that has hit my R&D team more times than missing semicolons or the like. The presumtion is the query will execute quickly because it does on their development system with only a few thousand rows in the tables. Even if the production database is the same size, it is more than likely going to be used a lot more, and thus suffer from other constraints like multiple users accessing it at the same time, or something going wrong with another query elsewhere, thus delaying the result of this query.
即使是像连接如何影响查询性能这样简单的事情,在生产中也是非常宝贵的。许多数据库引擎的许多特性在概念上让事情变得更简单,但如果没有考虑清楚,可能会在性能上带来问题。
了解数据库引擎的执行过程,并为之制定计划。
三件事是一个神奇的数字:
数据库也需要版本控制。 游标很慢,您可能不需要它们。 触发器是邪恶的*
*几乎总是
我希望每个人,包括dba和开发人员/设计人员/架构师,都能更好地理解如何正确地对业务领域建模,以及如何将业务领域模型映射/转换为规范化的数据库逻辑模型、优化的物理模型和适当的面向对象类模型(每种模型由于各种原因(可能)不同),并理解何时、为什么以及它们(或应该)如何彼此不同。
对于一个经常使用数据库(每天或几乎每天编写/维护查询)的中间派专业开发人员,我认为期望应该与任何其他领域相同:你在大学里写过一个。
每个c++极客在大学里都写过一个字符串类。每个图形狂人在大学里都写过一个光线追踪器。每个网络极客在大学里都写过交互式网站(通常在我们有“web框架”之前)。每个硬件书呆子(甚至软件书呆子)在大学里都做过CPU。大学里每个内科医生都解剖过一整具尸体,即使她今天只是给我量血压,告诉我胆固醇太高。为什么数据库会有所不同呢?
不幸的是,由于某种原因,他们今天看起来确实不一样了。人们希望。net程序员知道字符串在C语言中是如何工作的,但是RDBMS的内部结构不应该太关心你。
仅仅通过阅读,甚至从上到下都不可能达到同样的理解水平。但是,如果您从底层开始并理解每个部分,那么就相对容易找出数据库的细节。甚至是许多数据库极客似乎无法理解的事情,比如何时使用非关系数据库。
也许这有点严格,特别是如果你在大学里没有学习计算机科学。我会把它调低一些:你今天完全可以从头开始写一个。我不关心你是否知道PostgreSQL查询优化器的工作原理,但如果你知道足够多的知识自己编写一个,它可能不会与他们所做的有太大的不同。你知道,写一个基本的公式并不难。