📜  连接操作与 DBMS 中的嵌套查询

📅  最后修改于: 2021-09-10 02:16:21             🧑  作者: Mango

技术和自动化的发展以及指数数量的数据导致数据库的重要性和无处不在,简单地说,它是有组织的数据集合。考虑一种幼稚的方法,理论上可以将所有数据保存在一个大表中,但这会增加搜索记录的访问时间、主表破坏时的安全问题、信息的冗余存储等问题。所以表被分解成多个较小的表。

为了从多个表中检索信息,我们需要使用称为连接的操作(内连接、外连接和最重要的自然连接)从不同的记录中提取选定的数据。考虑具有 n 行的 2 个表模式员工(员工姓名、街道、城市)和带有 m 行的作品(员工姓名、分支名称、薪水)。这 2 个表的笛卡尔积创建了一个包含 n*m 行的表。自然连接从这 n*m 行中选择具有相同值的员工姓名的所有行。为了避免信息丢失(employee 中的一些元组在作品中没有对应的元组),我们使用左外连接或右外连接。

连接或嵌套查询更符合条件:

  • 假设我们的 2 个表存储在本地系统上。执行连接或嵌套查询几乎没有区别。现在让表存储在分布式数据库中。对于嵌套查询,我们只从位于不同计算机上的每个表中提取相关信息,然后合并获得的元组以获得结果。对于连接,我们需要从每个站点获取整个表并创建一个大表,从中进行过滤,因此需要更多时间。所以对于分布式数据库,嵌套查询更好。
  • RDBMS 优化器关注与程序员编写的子查询或连接相关的性能。联接被普遍理解,因此不会出现优化问题。如果需要跨多个平台的可移植性,请避免子查询,因为它可能会遇到错误(SQL 服务器更擅长连接,因为它通常与使用连接的 Microsoft 图形查询编辑器一起使用)。
  • 具体实现:假设我们有一些查询,其中一些嵌套查询是常量。在 MySQL 中,每个常量子查询都会根据遇到的次数进行评估,没有缓存设施。如果常量子查询涉及大元组,这是一个明显的问题。子查询返回一组数据。连接返回一个必须被索引的数据集。处理索引数据的速度更快,因此如果子查询返回的数据集很大,连接是一个更好的主意。
  • 子查询的执行时间可能比连接更长,这取决于数据库优化器如何处理它们(可能会转换为连接)。子查询比神秘的连接更容易阅读、理解和评估。它们允许采用自下而上的方法,依次隔离和完成每项任务。

参考 – 加入操作 Vs 嵌套查询