100加入SQL查询

Question

我希望基本上有一个集中的表，其中包含许多围绕它的查找表。中央表将用于存储“用户”，查找表将是用户属性，如“宗教”。中央表将存储Id，如ReligionId，查找表将包含宗教列表。

现在，我已经做了很多深入研究，我看到很多人评论说UserAttribute表可能是最好的方法，主要是使用EAV模式。我不打算这样做。我意识到我的策略会很重要，这就是我在这里问这个问题的原因。我正在寻找一种优化这些连接的方法。

如果该表有100个查找表，那么如何优化它才能比仅仅进行大量的100个表内连接更快？想到一些想法，比如使用许多较小的连接，子选择和视图。我对任何事情持开放态度，包括这些策略的组合。再次，请注意，我不打算做任何与EAV相关的事情。我出于其他原因需要查找表，我喜欢标准化数据。

考虑所有建议！

这是一个视觉效果：

编辑：这是疯了吗？

Answer 1

优化技术可能取决于中心表的大小和预期的查询模式。这与数据仓库中的星型模式非常相似，因此该模式的方法可能有所帮助。

首先，确保每行的大小尽可能小。磁盘空间可能很便宜，但磁盘吞吐量，内存和CPU资源都是潜在的瓶颈。您需要小行，以便它可以快速读取它们并尽可能地在内存中缓存。

已经执行了连接的实体化/索引视图允许连接基本上是预先计算的。如果您正在处理正在写入很多或非常大的中心表，这可能无法正常工作。

优化单个连接的任何操作都应该针对所有100进行。基于列的选择性等的适当索引

根据您正在执行的查询类型，可能会应用来自数据仓库或OLAP的其他技术。如果你要做很多小组，那么这可能是一个值得关注的领域。数据仓库技术可以在SQL Server中应用，无需额外的工具。

问问自己为什么要查询这么多属性以及如何呈现它们？对于大多数分析，没有必要连接查找表，直到您实现报表的最后一步，此时您可能只对列的子集进行分组，因此只需要一些查找表。

分组通常应该能够对查找ID进行分组而不需要查找表中的文本/描述，因此不需要连接。如果您的查找具有与手头查询相关的其他信息，则考虑将其非规范化到中央表中以消除连接和/或使该谨慎值成为其自己的查找，实质上将现有查找ID拆分为另一个ID。

您可以实现一个主代码表，该代码表将代码表组合到一个带有CodeType列的表中。这与EAV不同，因为您在每个代码类型的中心表中仍然有一个列，并且每个代码类型都有一个连接，其中EAV通常用于规范化任意数量的属性。 （注意：我个人讨厌主代码表。）

最后，如果您没有进行数据仓库，请考虑对中心表进行规范化。

某些lookupId列中是否有大量空值？桌子稀疏吗？这表明您可以将一些列拉出到1到1/0的关系，以减小中心表的大小。例如，包含地址信息的Person表可以从中拉出PersonAddress表。

如果存在大量行，则对表进行分区可能会提高性能，并且您可以确定某些行（可能具有过去几年的某个旧日期时间）很少会被查询。

更新：请参阅＆＃34;问问自己为什么要查询这么多属性以及如何呈现它们？＆＃34; 以上。考虑用户想知道按年份，部门和产品分组的销售数量。您应该拥有每个ID的ID，这样您就可以只按中心表上的这些ID进行分组，并在外部查询中查找仅查找剩余列的联接查找。这确保了聚合不需要从不需要的查找中提取不必要的信息。

如果您没有进行聚合，那么您可能无法一次查询大量记录，因此加入性能不太重要，应该使用适当的索引进行处理。

如果您一次查询大量记录并提取所有信息，我会仔细研究商业案例。没有人坐在他们的办公桌旁，打开一份包含一百万行和一百列的报告，并对所有这些数据做任何有意义的事情，而这些数据无法以更好的方式完成。

此类查询的唯一情况是转储所有要导出到另一个系统的数据，在这种情况下，性能不应该像关注一样多，因为它可以在一夜之间安排。

Answer 2

因为你已经开始了。您可以考虑复制数据，以便以与olap数据库中所做的相似的方式加入更少的时间。

http://en.wikipedia.org/wiki/OLAP_cube

据说，如果你有100个属性，我不认为这是最好的方法。

Answer 3

您是否尝试使用Power Query将其导出到Microsoft Excel Power Pivot？您可以使用Power view video sample

以非常棒的方式进行快速数据分析