0

我需要一些帮助来为我的一堆表构建基本的 SQL-VIEW。这是一个快速概述

  • 我有一个 ClaimDetail 表，它有一些查找字段，如 StatusID、BrandID、SalespersonID 等。
  • 像往常一样，查找字段映射到主表，如 MasterStatus、MasterBrand、... {Structure: ID, Title}
  • 还有另外两个表评论和文件。一个声明可以有多个评论和多个文件。
  • 我需要显示一个仪表板，它将是一个索赔列表。我需要显示主表中的标题以及评论和文件的数量。

现在，我有这个仪表板的两个视图，一个是针对客户类型的用户的，它仅限于某些细节，另一个是针对内部用户的详细视图。您可以说客户视图是内部视图的子集。

我看到两个选项 -

  1. 选项#1：创建单个 vw_Internal 视图并使用它为两个用户获取数据。
  2. 选项#2：我创建了一个vw_Customer ，它只包含客户所需的那些字段，然后我创建一个vw_Internal，它类似于：vw_Customer INNER JOIN 主表。简而言之，我将扩展基本的 vw_Customer 以包含更多字段。

从速度和性能的角度来看，选项#2 是否有意义？选项#1 很简单，但考虑到大量记录，我想确保客户不必为那些不会包含在他们的仪表板中的额外查找等待更长的时间。

最后，我提到的最后一个功能有办法吗？这是获取与 ClaimDetail 表具有一对多关系的 Comments 和 Files 的计数。我只需要计数或至少一个布尔字段，它说明索赔是否有任何评论（文件相同） - 如果计数 = 0，则为假。我也担心此功能对性能的影响.

提前致谢。

4

1 回答 1

1

关于视图定义，我将构建两个视图，并将它们分开——两个视图都不会引用另一个。这将允许您独立优化查询，并避免您在视图分层视图时遇到的任何问题；太多的层会使数据库管理、维护和重构特别具有挑战性。

至于数据聚合，常见的策略包括以下几种。比较、对比、测试和推断，看看什么最适合您的环境：

子查询

SELECT mt.Id, st1.HowMany, st2.HowManyOther, <etc>
 from MainTable mt
  inner join (select Id, count(*) HowMany
               from SubTable1
               group by Id) st1
   on st1.Id = mt.Id
  inner join (select Id, count(*) HowMany
               from SubTable2
               group by Id) st2
   on st2.Id = mt.Id

相当简单，尽管子查询可能会变得有点昂贵，即使有适当的索引。

计数（不同的 xx）

SELECT mt.Id, count(distinct st1.UniqueKey) HowMany, count(distinct st2.UniqueKey) HowManyOther, <etc>
 from MainTable mt
  inner join SubTable1 st1
   on st1.Id = mt.Id
  inner join SubTable2
   on st2.Id = mt.Id

这需要“子表”中的单个唯一列，如果您必须处理外部连接或 NULL，则会变得混乱。

添加

首先，在上述任一查询中用（左）外连接替换内连接将从子表中产生 0+ 个计数，只要您确保计数是在“右”表上完成的（因为 NULL 不会得到统计）。要确定哪个在您的环境中表现最好，您必须编写和测试这两个查询。我猜是第二个，因为第一个需要对子查询的表进行表扫描，而第二个执行连接，因此可能会优化得更好，但是 SQL 查询优化器比我更聪明（因为它知道您的索引并具有分布直方图你的数据）所以你想看看它会带来什么。

关于“分层视图”，如果我遵循正确的逻辑，我建议将内部视图构建为复杂/全面的查询（所有连接、所有相关列），然后构建希望的客户视图简单到

SELECT <customerOnlyColumns>
 from vw_Internal
于 2011-07-01T14:09:35.677 回答