wcf - 报告应用程序中的数据库抽象

Question

在报告应用程序中，是否可以抽象报告逻辑和数据库架构细节？

我有一个具有相当复杂的报告逻辑的 Reporting Services 应用程序，我正在尝试将应用程序迁移到其他一些数据库。（为相同目的而构建但由不同软件公司开发的数据库。）

在中间使用 Web 服务/WCF 层是明智的决定吗？还可以考虑哪些选项？

Answer 1

在一般情况下，很难以一种千篇一律的方式做这种事情，但你可以尝试其中一种：

• 在数据库架构上构建一些视图，并针对这些视图编写报告存储过程。这意味着您在底层数据库模式中具有一定的灵活性，并且可以将视图用作抽象层。

• 构建某种数据仓库平台并编写 ETL 流程以从各种数据源填充它。这更灵活，但构建起来更费力，它只能在定期刷新时工作。如果您的应用程序可以接受这种程度的延迟，那么我建议数据仓库系统是更好的方法。

  数据仓库的主要优势在于它针对报告进行了优化，并且在所有数据源中具有一致的界面——您可以将它们整合到具有一个模式的单个数据库中。报告是针对该模式开发的。添加新系统是通过编写 ETL 流程来填充仓库来实现的；无论数据来源如何，报告都会继续工作。

WCF是一个网络通信系统。您会发现很难让这种架构在逐个事务的基础上处理大量数据 - 批量加载 ETL 过程会更有效率。但是，如果您需要实时提要（可能是交易大厅系统），您可以使用类似的方法来实现。

如果您需要低延迟提要，另一种方法是研究一种称为Enterprise Information Integration的工具。也许可以做到这一点的最广泛可用的工具是SSIS中的数据源视图，它确实为您提供了将任意数据源映射到一致模式的一些灵活性。它不像最好的 EII 工具那样复杂，但是如果您需要进一步转换数据，您可以将 SSIS 包放在它之上，并将它们用作您的报告的数据源。

但是，我从来没有构建过这样的系统，所以我不能真正保证它在实践中的效果如何。我猜想它会非常脆弱并且很难分解成可以进行单元测试的部分，因此对于一个非常复杂的系统来说，开发和维护将非常耗时。

如果您想调查市场上的其他 EII 系统此链接是有关 EII 和其他一些 EII 工具供应商的各种文章的目录。

Answer 2

我同意 NXC 的数据仓库建议：

• 如果它是一次性工作，则不会，但由于它是一个“报告应用程序”，因此您的许多报告很可能适合 OLAP 范式。
• 这显然是一项可行的任务，因为市场上有许多成功的 OLAP 查询工具，其复杂程度各不相同
• OLAP 模式，例如标准星型模式，被设计为易于查询。它们本质上是扁平的，事实表使用简单的键以非常直接的方式连接到一个或多个维度表。
• 人们希望对报告执行的操作类型是可预测的：过滤、排序、分组、添加或删除列、导出到 CSV 等。
• 您将通过生成的报告获得良好的灵活性 - 探索各种关系的数据的能力非常令人上瘾
• 一旦您编写了查询工具，它就可以移植以与任何其他星型模式重用 - 不错！
• “是否可以抽象报告逻辑和数据库架构细节？” - 是的，OLAP 模式正是为此而设计的 - 它们使所有数据都符合标准化模式。当然，这会将业务逻辑转移到 ETL 层，但我认为这是它所属的地方。

因此，您需要使用这种方法执行 ETL - 一种选择是执行某种形式的ROLAP，但实际上我发现编写 ETL 脚本与从 ROLAP 设置中获得良好性能一样容易。

Answer 3

我认为通常会在后面咬你的答案，但我认识的其他人喜欢的答案是将每个数据库中的数据生成为 XML。这以大多数产品可以轻松处理的形式为您提供了一组一致的数据。

如果您这样做，请确保您将在其上运行的 XPath 查询会很快。