我有动力在OLAP多维数据集中存储一些长文本字符串，长达1,000或10,000个字符的数量级 - 但我想知道这是否会让我误入歧途。 （我也很想知道OLAP引擎如何处理字符串。）我想到的具体用例是我对每个OLAP事实都有一个独特的，预先存在的“记录描述”，而我想要将这些描述放在多维数据集中，以便我可以选择在执行DRILLTHROUGH操作时将它们取回。相反，在进行正常的数据透视表/聚合类型操作时，我不需要显示记录描述。 （描述太长，无法在数据透视表中显示，加上每个事实都有一个独特的描述，这意味着聚合描述没有意义。）我当前的数据集有大约700,000个事实，但我也很好奇，如果对于较大的数据集，答案会发生变化。
我希望如果我将这些长字符串放在一个多维数据集中，OLAP服务器可以做一些合理的事情。特别是在Sql Server / SSAS案例中，我想也许我会将它们放在标记为ROLAP的维度中，以节省内存使用量，并使用简并维度（在SSAS术语中称为“事实维度”），以避免不必要的ETL复杂性。但我很好奇，如果出于某种原因将其视为一种可怕的做法，或者是否有任何隐藏的陷阱。
更新：我的示例用例是您拥有与每个OLAP事实相关联的字符串的位置。但考虑字符串与特定维度的每个特定值相关联的情况也可能是有益的。 （例如，假设您有一个公司维度，并且每个公司都有一个有点冗长的公司描述字符串。）
答案 0 :(得分：3)
以下是我能够揭示在SSAS中存储此类字符串的含义，特别是SSAS 2008.在我考虑数据结构时，它专注于MOLAP存储，这是我一直在尝试的。 / p>
首先，像Business Intelligence Development Studio这样的标准MS ETL（提取/转换/加载，即数据导入）工具可能会阻止您导入大型文本字段，尤其是varchar（max）字段，但是有一种解决方法，它是证明对我有效。 （对于BIDS，它涉及在XML文件中手动设置DataSize元素，可能达到163315555字节的魔术大小。道具为Matija Lah以便解决这个问题。）
其次，据我所知，存储大量长而独特的字符串不应该对SSAS使用的磁盘上数据结构造成严重破坏。此外，磁盘上字符串数据的大小应与数据源中的字符串数据的大小相同。以下是SSAS处理字符串的一些粗略信息：
我已经通过实验验证了文本数据采用相同的字节数量级，无论是存储在SSAS MOLAP还是存储在sql表中。特别是，我从我的一个维度表中选择了“mytable”中的“选择总和（len（myfield））”，然后将其与SSAS数据目录中相应属性文件的大小进行比较。 SQL的大小为172MB，SQL服务器的大小为304MB。 （如果我总结所有唯一字符串，而不是所有字符串，则Sql大小为147MB。）在我的情况下，大小差异主要通过字符编码来解释;我的源sql数据每个字符存储一个字节，而SSAS存储每个字符两个字节的所有字符串。我发现.kssstore文件完全控制了与此属性关联的所有其他文件的大小，无论我是否通过AttributeHierarchyOptimizedState = FullyOptimized优化了该属性。
第三，字符串存储文件的大小有4GB上限，这限制了可以与特定维度/属性关联的唯一文本的数量。在我的情况下，我只有不到10％的限制，但这可能会影响一些人。 （原始帖子的快速数量级计算：1M事实* 10,000字节/每个事实= 10GB-ish值的文本。）如果达到此限制，您显然会在立方体“处理”时间点击它。显然它甚至适用于ROLAP尺寸。可能有一些黑客可以解决这个问题。见here。请注意，Sql Server 2012 may remove this 4GB limitation。
第四，似乎如果长的唯一字符串在SSAS中产生问题，它们就会在内存表示层面上这样做。一个潜在的问题（我没有详细研究）是将这些额外的字符串缓存在内存中将使SSAS不会将其他重要的数据结构保留在内存中，从而降低性能。本书The Microsoft Data Warehouse Toolkit（虽然我还没有在其他地方找到这个说法）所提出的另一个问题是SSAS在其内存数据结构中做了一些扩展的字符串填充：
“关系数据库存储可变长度的字符串列...但是，SQL Server工具集的其他部分会将这些列填充到它们的整个宽度。值得注意的是，Integration Services和Analysis Services在填充空格时填充字符串列进入内存.Integration Services和Analysis Services都喜欢物理内存，因此声明字符串列的成本要比它们需要的要宽得多。“
总而言之，到目前为止，将我的长字符串数据存储在多维数据集中似乎很方便，而且我没有发现任何期望发生灾难的理由，所以我试一试。如果事情没有成功，我会尝试提供更新。
答案 1 :(得分：1)
您可以将值存储在关系表中，然后创建整数代理键。
将整数代理项添加到您的UDM并创建SSRS钻取操作
http://msdn.microsoft.com/en-US/library/ms174526(v=SQL.90).aspx
按键值查找文本字段。
答案 2 :(得分：0)
我会使用退化维度，但通过SSAS隐藏它，直到通过钻取行动请求。
我无法指导您为AS引擎的字符串内部存储，但是为了将它们存储在SQL中，我会确保您的varchar（MAX）列位于列的末尾以加速SQL引擎扫描那些行。
700,000行，有足够的内存和磁盘I / O，你不会对SQL征税太多。
答案 3 :(得分：0)
还没有完成所描述的所有可能性并从中链接到它，但是2007年的这个主题是关于同一主题并且看起来非常相关：
这里提出的一个新的可能性是，您可以将其视为文本值（与数值相对）