多年来，我读到很多人对如何从他们的sql（microsoft sql server，我们都在同一页……）查询中获得更好的性能的意见。然而，它们似乎都与高性能oltp设置或数据仓库olap设置（cubes galore…）紧密相连。然而，我今天的处境有点介于两者之间，因此我犹豫不决。
我有一个通用的数据库结构，[联系人]，[站点]，[站点联系人]，[站点特征]和[合同特征]的连接表。我有近300万个联系人，大约有50个字段（在[联系人]和[联系人特征]之间）仅与联系人有关，大约有60万个站点，大约有150个字段（在[站点]和[站点特征]之间）仅与这些站点有关。基本上它是一个相当大的扁平表或视图…大多数列是int、bit、char（3）或short varchar（s）。我的问题是，这些列中有很大一部分可供用户在特别查询中使用，并且可以尽快使用，因为主要用户界面是一个网站。我知道最常见的过滤器，但即使有很重的索引，我认为这仍然是一个野兽…这个数据是只读的；数据在一天中根本不会改变，并且数据库只会在计划停机期间用最新的信息刷新。因此，我将这种情况视为具有oltp数据库的读取需求的olap数据库。
我看到3个选择；1。将表分解成更小的可分割单元子查询所有内容，2。制作一张平桌子，并在索引3上真正进入城镇。创建一个olap多维数据集，并根据我没有将哪些过滤值作为多维数据集维度进行子查询，以及。我对olap多维数据集做得不多，所以我甚至不知道这是否是一个选项，但从我过去对它们做的事情来看，我认为这可能是一个选项。另外，为了澄清我所说的“子查询所有内容”的意思，不是在外部select上有where子句，而是在每个表被带入查询时都有一个where子句（如果适用），然后表被内部连接，以消除一个非常大的笛卡尔积。至于一个大表的第二个选项，我听说并看到了与该方法相冲突的结果，因为它将节省连接时间，但同时表扫描需要更长的时间。
有主意吗？我需要分享我吸烟的内容吗？我认为如果每个人都投入2美分的话，这会变成一个很好的讨论。哦，如果我对olap多维数据集的想法不太了解，请随时告诉我，如果是这样的话，我也不太熟悉这些东西。
提前感谢所有的意见和帮助我解决这个困境我发现自己。
最佳答案
您可能希望将其视为关系数据仓库。可以将关系数据库表设计为星型模式（或雪花模式）。这种设计与olap多维数据集的逻辑结构非常相似，但物理结构在关系数据库中。
在星型模式中，您将拥有一个或多个事实表，它们表示某种类型的事务，通常与日期关联。不过，我不确定这种情况下的交易是什么。事实可能是网站与联系人和表的关联。
事实表将引用描述事实的维度表。维度可能是站点和联系人。维度包含属性，如联系人姓名、联系人地址等。如果您熟悉olap多维数据集，那么这将是一种熟悉的逻辑体系结构。
在体系结构中添加大量索引并不是什么大问题。除了刷新时间之外，数据库大部分是只读的。在更新索引时，不必担心读取性能。因此，该体系结构可以容纳所需的所有索引（只要您能够留出足够的停机时间来刷新数据）。