多年来，我已经阅读了很多人关于如何通过SQL（Microsoft SQL Server，以及我们都在同一页面上...）查询来获得更好性能的意见。但是，它们似乎都与高性能OLTP设置或数据仓库OLAP设置（多维数据集 - 嘉豪......）紧密相关。但是，今天我的情况有点在2的中间，因此我犹豫不决。
我有[Contacts]，[Sites]，[SiteContacts]（[Sites]和[Contacts]的联结表），[SiteTraits]和[ContractTraits]的通用DB结构。我有近300个联系人，有大约50个字段（[联系人]和[联系人跟踪]之间）与联系人有关，大约60万个网站有大约150个字段（在[网站]和[SiteTraits]之间）与网站有关。基本上它是一个相当大的扁平表或视图...大多数列是 int ，位， char（3），或短 VARCHAR （S）。我的问题是这些列中的很大一部分可用于用户的即席查询，并且尽可能快，因为这个列的主UI将是一个网站。我知道最常见的过滤器，但即使对它们进行大量索引，我认为这仍然是一个野兽...这个数据是只读的;数据在白天根本不会改变，数据库只会在计划停机期间使用最新信息刷新。所以我认为这种情况就像OLAP数据库一样，具有OLTP数据库的读取要求。
我看到3个选项; 1.将表分成较小的可分单元子查询所有内容，2。制作一个平面表并真正进入索引的城镇3.创建一个OLAP多维数据集并根据我未放置的过滤器值对其余的进行子查询作为立方体尺寸，和。我没有对OLAP多维数据集做过多少工作，所以我坦率地甚至都不知道这是否是一个选项，但从过去我对它们所做的事情来看，我认为它可能是一种选择。另外，为了澄清当我说“子查询所有内容”而不是在外部选择上有一个WHERE子句时，我的意思是，每个表的一个（如果适用）被带入查询，然后表是INNER JOINed，消除了一个非常大的笛卡尔积。至于一个大表的第二个选项，我听到并看到了与该方法相矛盾的结果，因为它将节省连接，但同时表扫描需要更长的时间。
任何人的想法？我需要分享我吸烟的吗？如果每个人都投入2美分，我认为这可能会成为一个非常好的讨论。哦，如果情况确实如此，我可以随意告诉我，如果我不喜欢OLAP多维数据集的想法，我也是那些新手。
提前感谢任何和所有意见，并帮助我解决这个困境。
答案 0 :(得分：2)
您可能希望将其视为关系数据仓库。您可以将关系数据库表设计为星型模式（或雪花模式）。此设计与OLAP多维数据集逻辑结构非常相似，但物理结构位于关系数据库中。
在星型模式中，您将拥有一个或多个事实表，这些事务表表示某种事务，通常与日期相关联。我不确定在这种情况下交易可能是什么。事实可能是网站与联系人和桌子的关联。
事实表将引用描述事实的维度表。维度可能是站点和联系人。维度包含属性，例如联系人姓名，联系人地址等。如果您熟悉OLAP多维数据集，那么这将是一个熟悉的逻辑体系结构。
向您的架构添加众多索引不会是一个非常大的问题。除刷新时间外，数据库大部分是只读的。在更新索引时，您不必担心读取性能。因此，该体系结构可以容纳所有需要的索引（只要您可以将足够的停机时间用于刷新数据）。
答案 1 :(得分：1)
我同意bobs的回答：抛出一个OLAP前端并通过多维数据集进行查询。这将是一个很好的思考的原因是多维数据集在多维度查询（通常是预先计算的）聚合时非常高效，并且它们以面向列的格式存储数据，这对于数据分析更有效。
多维数据集下面的关系数据对于详细钻取来说非常有用，可以找到提供某个聚合值的各个事实。但直接查询关系数据总是很慢，因为只有扫描大量数据才能产生用户对分析感兴趣的聚合。 OLAP在这方面做得更好。
答案 2 :(得分：0)
OLAP / SSAS对于聚合查询是有效的，而不是我体验中的粒度数据。
最常见的查询是什么？对于单件数据或聚合？
答案 3 :(得分：0)
如果SiteContacts的粒度与Contacts的粒度非常接近（即大约300万条记录 - 大多数联系人只与一个站点相关联），您可以从单个表中获得最佳性能（具有大量适当的索引） ，显然;也应该考虑分区）。
另一方面，如果大多数联系人与许多站点相关联，那么坚持使用接近当前架构的东西可能会更好。
OLAP倾向于在聚合数据上产生最佳结果 - 听起来好像对这些数据进行的聚合相对较少。
星型模式由尺寸悬挂在它们上面的事实表组成 - 取决于网站和联系人之间的关系，听起来好像你有一个巨大的维度表，或者两个大尺寸与一个无事实的事实表（听起来像矛盾） ，但在Kimball的方法中有所涉及）。