Reporting services 数据库（OLTP）和报告

我在一个交易平台上工作，该平台的大部分业务都是报告

设置如下： SQL OLTP数据库（大约200个表）——记录数量非常少。（20000张记录了最大的表格，但每周都在增长） 对于reporting services，SQL视图用于查询实时事务数据库。按照数据仓库方法的精神，设想视图的结果集是非规范化的。然后将这些数据集传递给第三方报告平台（如Tableau、Power Bi或SiSense），该平台将这些数据集放入多维数据集（可能是一些柱状结构，如mono db、hadoop等）。从那里生成报告

当前的挑战。 SQL视图（大约8个）。体积巨大，很难维护。举个例子，其中一个视图输出100个字段。但这些字段中的每一个都是计算字段，包含复杂的CASE语句、嵌套的IF语句、内联函数等等，这使得该视图的sql代码行数高达700行。我从另一位员工那里继承了这些，现在，遗憾的是，，我不得不保留它们。 由于数据每周增加数百条记录（通过迁移和事务），并且视图中的字段数量也在增加（每周增加几个），因此多维数据集的构建时间越来越长。举个例子，几个月前，我们设置了一个立方体，每次10分钟重新构建一次以刷新数据（需要5分钟）。目前构建需要12-15分钟，因此我们每30分钟设置一次。可以想象，随着数据和字段数量的不断增长，情况会变得更糟；我们需要尽可能最新的数据

唯一的好处是，一旦构建了多维数据集，报告加载速度很快，因为它们是从第三方平台拉出来的，所以这里不需要担心

我的想法 我想去掉视图，这样我就可以简化维护过程，并将重建多维数据集的时间保持在最低限度

选项：

建立一个数据仓库。然后构建SSIS包，用实时事务数据填充此结构。非规范化结构可能与上述视图非常相似。这里的缺点是，我并不觉得我简化了很多，实际上我又增加了一层，即从OLTP到OLAP（数据仓库）的数据迁移。我仍然需要重新构建立方体

要将当前视图转换为SQL索引视图（物化视图），但在它们的当前状态下，我无法这样做，因为在整个视图中大量使用了agregate和内联函数

我提到的另一个选择是使用触发器或事务日志构建ODS（操作数据存储——它将是一个包含与我现在的sql视图类似的必要表的数据库——并不断刷新它）？但我不确定建造这样的东西需要什么，维护起来有多困难

问题： 我应该采取什么方法？ 以上三项中的任何一项有意义吗？ 当然，我对其他想法或建议也感兴趣。

---

谢谢大家!

根据我的经验，你最好的方法是1。这是昂贵的，但会给你更好的好处。创建一个ROLAP DWH（我推荐Kimball的“数据仓库工具包”用于最佳实践和设计模式），如果您有机会使用一个列式数据存储（如amazon redshift或sap sybase iq），所有案例语句、嵌套ifs和您提到的所有操作都将在ETL时间应用，因此，在ROLAP中，一切都是预先计算和优化的，以满足消费需求。不要忘记应用索引（取决于您使用的技术）。一些数据库供应商已经发布了ROLAP的“索引最佳实践”，因此他们会根据表的类型（维度）和数据类型（例如）告诉您哪种类型的索引。

根据我的经验，您的最佳方法是1。这是昂贵的，但会给你更好的好处。创建一个ROLAP DWH（我推荐Kimball的“数据仓库工具包”用于最佳实践和设计模式），如果您有机会使用一个列式数据存储（如amazon redshift或sap sybase iq），所有案例语句、嵌套ifs和您提到的所有操作都将在ETL时间应用，因此，在ROLAP中，一切都是预先计算和优化的，以满足消费需求。不要忘记应用索引（取决于您使用的技术）。一些数据库供应商已经发布了ROLAP的“索引最佳实践”，因此他们将根据表的类型（维度）和数据类型（例如）告诉您哪种类型的索引。

Hi Luis Leal。谢谢你的回复。是的，数字1是我的第一个选择，但目前在SiSense中，数据每隔30分钟通过多维数据集刷新一次，我们希望保持不变，不超过30分钟。因此，通过构建数据仓库，意味着我将通过另一层（即ETL）增加流程的复杂性，这将延长数据刷新的时间。因此，现在通过SQL视图（直接从Live中提取）的不是一个进程，而是带有必要逻辑（所有这些case语句）的包，这些包将把Live中的数据形式提取到DW中。然后，SiSense多维数据集仍然需要从这些数据仓库表中提取它。而且，它们不断改变如何通过case语句提取这些字段的逻辑，我想知道维护是否会更糟糕，在SSIS中进行，而不是在SQL视图中进行。因此，我仍然不知道什么是最好的方法。：）嗨，路易斯·莱尔。谢谢你的回复。是的，数字1是我的第一个选择，但目前数据通过SiSense中的多维数据集每30分钟刷新一次，我们希望保持不变