Wcf 报表应用程序中的数据库抽象

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

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

---

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

在一般情况下，很难做到一刀切，但您可以尝试以下选项之一：

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

• 建立某种数据仓库 平台，并编写一个ETL流程 从各种数据源填充它。这更灵活，但构建起来更费劲，而且只能在定期刷新后才能工作。如果您的应用程序可以接受这种延迟程度，那么我建议数据仓库系统是更好的方法
  数据仓库的关键优势在于，它针对报告进行了优化，并且在所有数据源之间具有一致的接口—您可以将它们整合到一个具有一个模式的单个数据库中。这些报告是根据该模式开发的。添加新系统是通过编写ETL流程来填充仓库来实现的；无论数据源如何，报告都会继续工作

WCF是一种网络通信系统。您会发现，很难让这种体系结构逐个事务地处理大量数据——批量加载ETL过程将更加高效。然而，如果你需要一个实时的feed（也许是交易大厅系统），你可以用这样的东西来实现

如果您需要一个低延迟的feed，另一种方法是研究一种称为。也许可以实现这一点的最广泛可用的工具是一个，它在将任意数据源映射到一致模式方面提供了一定的灵活性。它没有同类最佳的EII工具那么复杂，但如果需要进一步转换数据，您可以将SSIS包放在上面，并将其用作报表的数据源

然而，我从来没有建立过这样的系统结构，所以我不能保证它在实践中运行得有多好。我猜它将非常脆弱，很难分解成可以进行单元测试的部分，因此对于一个非常复杂的系统来说，开发和维护将非常耗时

---

如果您想调查市场上的其他EII系统，请参阅关于EII和其他EII工具供应商的各种文章目录。

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

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

---

因此，您需要使用这种方法进行ETL—一种选择是进行某种形式的ETL，但在实践中，我发现编写ETL脚本与诱骗ROLAP设置的良好性能一样容易。

我认为这个答案通常会反过来咬到您，但我知道其他人喜欢，就是从每个数据库生成XML格式的数据。这将以大多数产品都可以轻松处理的形式为您提供一组一致的数据

---

如果执行此操作，请确保将在其上运行的XPath查询将是快速的。

此外，星型模式非常宽容源数据的精确基数。它们非常扁平，因此很容易将任意关系和层次映射到一组合理选择的维度。