在OLAP多维数据集中存储长且唯一的文本字符串以供钻取检索（特别是在SSAS中）是否明智？
我很想在OLAP多维数据集中存储一些长文本字符串，长度大约为1000或10000个字符——但我想知道这是否会让我误入歧途。（我还想了解更多关于OLAP引擎如何处理字符串的知识。）我想到的特定用例是，我的每个OLAP事实都有一个唯一的、预先存在的“记录描述”，我想将这些描述放在多维数据集中，以便在执行钻取操作时可以选择将它们取回。相比之下，我不需要在执行常规透视表/聚合类型操作时显示记录描述。（描述太长，无法在数据透视表中合理显示，再加上每个事实都有一个唯一的描述，这意味着聚合过多的描述是没有意义的。）我当前的数据集大约有700000个事实，尽管我也很好奇，对于更大的数据集，答案是否会改变 我的希望是，如果我将这些长字符串放入多维数据集中，OLAP服务器可以做一些明智的事情。特别是在Sql Server/SSAS案例中，我想也许我应该将它们放在标记为ROLAP的维度中，以节省内存使用量，并使用退化维度（在SSAS术语中称为“事实维度”），以避免不必要的ETL复杂性。但我很好奇，出于某种原因，这是否会被视为一种可怕的做法，或者是否存在任何隐藏的陷阱在OLAP多维数据集中存储长且唯一的文本字符串以供钻取检索（特别是在SSAS中）是否明智？,ssas,olap,drillthrough,Ssas,Olap,Drillthrough,我很想在OLAP多维数据集中存储一些长文本字符串，长度大约为1000或10000个字符——但我想知道这是否会让我误入歧途。（我还想了解更多关于OLAP引擎如何处理字符串的知识。）我想到的特定用例是，我的每个OLAP事实都有一个唯一的、预先存在的“记录描述”，我想将这些描述放在多维数据集中，以便在执行钻取操作时可以选择将它们取回。相比之下，我不需要在执行常规透视表/聚合类型操作时显示记录描述。（描述太长，无法在数据透视表中合理显示，再加上每个事实都有一个唯一的描述，这意味着聚合过多的描述是没有意义
更新：我的示例用例是，您有一个与每个OLAP事实关联的字符串。但是考虑字符串与特定维度的每个特定值相关联的情况也可能具有启发性。（例如，假设您有一个公司维度，而每个公司都有一个较长的公司描述字符串。）以下是我在SSAS中存储此类字符串的含义，特别是SSAS 2008。在我考虑数据结构的时候，它只关注MOLAP存储，这是我一直在试验的。 首先，像Business Intelligence Development Studio这样的标准MS ETL（提取/转换/加载，即数据导入）工具可能会试图阻止您导入大型文本字段，特别是varchar（max）字段，但有一个解决方法，它对我来说是行之有效的。（对于BIDS，它涉及到在XML文件中手动设置DataSize元素，可能会设置为16315555字节的神奇大小 第二，据我所知，存储大量长且唯一的字符串不应该对SSA使用的磁盘数据结构造成严重破坏。此外，磁盘上字符串数据的大小应该与数据源中的字符串数据具有相同的数量级。以下是有关SSAS句柄字符串的一些粗略信息：
- 核心OLAP数据结构（例如，维度属性或度量值组事实）不直接包含字符串；而是将偏移量包含到包含实际字符串数据的“字符串存储”文件（扩展名.ksstore、.asstore、.bsstore或.string.data）中
- 在给定的字符串存储中，每个字符串只表示一次。如果源数据表中的几行包含重复的字符串，那么在SSAS/MOLAP级别，这将转换为重复的文件偏移量，而不是重复的字符串值
- 如果源字符串的长度为n，则字符串存储中相应的数据结构的开销为8字节，每个字符加上2*n字节。（字符串固有地以2字节Unicode格式存储在SSAS中。）
- 关于这些东西的一些奇妙的细节，我推荐这本书，特别是第20章，“物理数据模型”
- 至少在我的实验中，字符串存储文件似乎并没有被压缩——至少它们不会比未压缩的字符串存储明显小