100加入SQL查询

Question

我期待本质上有一个集中的表与周围的查找表的数量。中央表将用于存储'用户'，查找表将是用户属性，如'宗教'。中央表将存储Id，如ReligionId，查找表将包含宗教列表。

现在，我已经做了大量的研究，我看到很多人评论说UserAttribute表可能是最好的方式，基本上使用EAV模式。我不想这样做。我意识到我的战略会变得沉重，这就是为什么我在这里问这个问题的原因。我正在寻找一种方法来优化这些连接。

如果表中有100个查找表，那么它如何被优化为比只进行大量100个表内连接更快？想到一些想法就像使用许多较小的联接，子选择和视图一样。我愿意接受任何事情，包括这些策略的组合。再说一遍，我不打算做任何与EAV相关的事情。我需要其他原因的查找表，我喜欢规范化的数据。

所有建议考虑！

这里有一个视觉效果：

编辑：这是疯了吗？

Answer 1

优化技术将很可能取决于中间表的大小和预期的查询模式来显示它快速的数据分析。这非常类似于您在数据仓库星型模式得到什么，所以从接近该模式可能会有帮助。

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

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

，您可以做优化单个连接应该做的基于列的选择性全部100个合适的索引，等等

根据您要执行什么样的查询，然后从其他技术数据仓库或OLAP可能适用。如果你正在做很多的分组，那么这可能是一个需要注意的地方。数据仓库技术可以在SQL Server中应用，不需要额外的工具。

问自己，为什么这么多的属性被查询以及它们是如何呈现？对于大多数分析而言，在实现报告的最后一步之前，不需要加入查找表，此时您可能只能按列的子集进行分组，因此只需要一些查找表。

Group By的一般应该能够在查找表上分组而不需要查找表中的文本/描述，因此不需要连接。如果您的查询包含与查询相关的其他信息，则可以考虑将其非规范化到中央表中，以消除连接并/或将该谨慎值自己查找，从而将现有查找ID拆分为另一个ID。

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

最后，考虑规范化中心表，如果你不做数据仓库。

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

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

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

如果您没有进行聚合，那么您可能一次不会查询大量记录，因此，连接性能不太关注，应该使用适当的索引来处理。

如果您在查询大量记录时一次抽取所有信息，我会仔细看看这个商业案例。没有人坐在办公桌前，打开一个有100行100列的报告，对所有这些数据做了任何有意义的事情，这些都无法以更好的方式实现。

这种查询的唯一情况是所有数据的转储，以便导出到另一个系统，在这种情况下，性能不应该像担心的那样在一夜之间安排。

Answer 2

既然你设置了你的方式。您可以考虑复制数据以便以类似于olap数据库中所做的方式加入更少的时间。

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

虽这么说，我不认为这是做，如果你有100个属性的最佳方法。

Answer 3

你试过将它与电源查询导出到Microsoft Excel数据透视权力？你可以用很要命的方式与电力视图video sample