【问题标题】:Use 'UNION ALL' in oracle SQL or not?在 oracle SQL 中是否使用“UNION ALL”?
【发布时间】:2018-11-24 17:10:21
【问题描述】:

我正在尝试使用 C# WPF 视图显示员工属性。我的数据库中有不同的 oracle 表中的数据。

虽然有一组多个表,但每组都包含相同的结构。那些高层次的表结构是......

表格结构

Employee table columns            (EMP table)  : ID, Name, Organisation
Employee properties table columns (EMPPR table): ID, PropertyName, PropertyValues

EMP 表中每个员工的 ID 和姓名以及 EMPPR 表中的员工属性。每个员工都有 40-80 的属性,即 EMPPR 表中每个员工 40-80 行。

这样每个部门都有一组表。即(DEVEMP,DEVEMPPR), (HREMP,HREMPPR), (ADMINEMP, ADMINEMPPR), (FINEMP, FINEMPPR), (ADMINEMP, ADMINEMPPR)等等...

我需要一次获取多个部门的员工属性,以获取部门明智的员工姓名列表。

我正在使用以下查询来获取输入姓名的员工属性,如下所示:

SELECT Pr.PropertyName, Pr.PropertyValue
FROM DEVEMP Emp
JOIN DEVEMPPR Pr ON Emp.ID = Pr.ID
AND Emp.Name IN (<List of DEV Names Inputted>)

这样,我需要为每个部门执行。

如果我将 UNION ALL 与所有部门表查询和 IN 条件与以下组合列表一起使用,查询会有效吗?

使用 UNION ALL 查看

CREATE OR REPLACE FORCE VIEW EMPPRVIEW(NAME, PRNAME, PRVALUE) AS

SELECT Emp.Name, Pr.PropertyName, Pr.PropertyValue
FROM DEVEMP Emp
JOIN DEVEMPPR Pr ON Emp.ID = Pr.ID

UNION ALL

SELECT Emp.Name, Pr.PropertyName, Pr.PropertyValue
FROM HREMP Emp
JOIN HREMPPR Pr ON Emp.ID = Pr.ID

UNION ALL

SELECT Emp.Name, Pr.PropertyName, Pr.PropertyValue
FROM ADMINEMP Emp
JOIN ADMINEMPPR Pr ON Emp.ID = Pr.ID

UNION ALL

.
.
.

来自视图的查询

SELECT NAME, PRNAME, PRVALUE
FROM EMPPRVIEW
WHERE NAME IN (<Combined list of names from each dept>)

方法 #2 很容易实现,因为我们一次执行查询,但我认为它会降低查询性能。

UNION ALL 的单一查询执行或每个部门的单独查询执行哪种方法更好?

PS。输入的emp名称列表可能包含每个部门的1000个名称,每个员工有40-80个属性。

【问题讨论】:

  • UNION ALL 只是一个查询,而不是分隔的查询与您一样多.. 所以通常 UNION ALL 查询的性能更高
  • 表结构为foobar。除非你修复它,否则这可能是你最好的选择。
  • 如何使用 VIEW(已编辑问题)?即使仍然使用 VIEW 也是一个不错的选择?
  • 嗯,我的印象是,这两种方法都差不多效率低下。摆脱这个 NoSQL 表设计(完全不适合关系数据库)的唯一选择是 IMO 采用你的大 UNION ALL view,将其转换为 物化查看 添加属性索引并对其进行查询。
  • 我同意这应该重新设计,你应该向控制这些东西的人提出建议。没有高效的查询,只有一个性能足以满足您的目的的查询。将其转换为视图可能对查询性能没有影响。

标签: sql oracle union-all sqlperformance


【解决方案1】:

我同意 MatBailie 的观点;这应该作为单个 Employee 表中的列来完成。您可以将其更改为此,并创建镜像现有表结构的可更新视图,以便应用程序在您将其切换为使用单个统一的员工表时继续工作

就您询问查询效率和大概的性能而言,您将不得不对其进行测试。如果 oracle 在联合操作期间不会在每个表上使用索引,我只会预见到性能问题。

所以回答你的问题:它会起作用,但你应该考虑改变结构,而不是坚持寻找方法来绕过有问题的初始设计决策。知道它是否能满足您的要求的唯一方法是对其进行(压力)测试

【讨论】:

  • 对不起。我无法更改数据库设计,这不在我的手中。应用程序上下文和用法完全不同。只是为了解释的目的,我使用了上面的例子。
猜你喜欢
  • 2013-01-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-24
  • 2013-08-20
  • 1970-01-01
  • 2016-09-01
  • 1970-01-01
相关资源
最近更新 更多