报告应用程序中的数据库抽象
在报告应用程序中，是否可以抽象报告逻辑和数据库架构详细信息？
我有一个具有相当复杂的报告逻辑的 Reporting Services 应用程序，我正在尝试将该应用程序迁移到其他一些数据库。 （为相同目的而构建但由不同软件公司开发的数据库。）
在中间使用 Web 服务/WCF 层是明智的决定吗？ 还可以考虑哪些选择？
In a reporting application, Is it possible to abstract reporting logic and the database schema details?
I have a Reporting Services application with a reasonably complex reporting logic, I am trying to migrate the application to some other databases. (Databases that are built for the same purpose but developed by different software-houses. )
Is it a wise decision to use a web services / WCF layer in the middle? What else options can be considered?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在一般情况下，很难以一种一刀切的方式完成这类事情，但您可以尝试其中之一：
在数据库架构上构建一些视图，并
编写报告过程
那些。 这意味着您在底层数据库架构方面具有一定的灵活性，并且可以使用视图作为抽象层。
构建某种数据仓库
平台并编写ETL流程
从各种数据源填充它。 这更灵活，但需要更多的精力来构建，并且只能通过定期刷新来工作。 如果您的应用程序可以接受这种程度的延迟，那么我建议数据仓库系统是更好的方法。
数据仓库的主要优势在于，它针对报告进行了优化，并且在所有数据源之间具有一致的界面 - 您可以将它们合并到具有一种模式的单个数据库中。 这些报告是根据该模式开发的。 添加新系统是通过编写ETL流程来填充仓库来实现的； 无论数据源如何，报告都会继续工作。
WCF是一个网络通信系统。 您会发现很难让这种架构在逐个事务的基础上处理大量数据 - 批量加载 ETL 过程会更加高效。 但是，如果您需要实时源（可能是交易大厅系统），您也许可以使用类似的方法来实现。
如果您需要低延迟源，另一种方法是研究一种名为企业信息集成。 也许可以执行此操作的最广泛使用的工具是数据源视图 在 SSIS 中，这确实为您在映射任意数据源方面提供了一定的灵活性一致的模式。 它不像最好的 EII 工具那么复杂，但如果您需要进一步转换数据，您可以将 SSIS 包放在其上并使用它们作为报告的数据源。
但是，我从未构建过这样的系统，因此我无法真正保证它在实践中的效果如何。 我猜想它会非常脆弱并且很难分解成可以进行单元测试的部分，因此对于一个非常复杂的系统来说，开发和维护将非常耗时。
如果您想调查市场上的其他 EII 系统此链接是有关 EII 和其他一些 EII 工具供应商的各种文章。
It would be hard to do this sort of thing in a one-size-fits-all way in the general case but you could try one of these:
Build some views over the database schema and
write the reporting sprocs against
those. This means that you have some flexibility in the underlying database schema and can use the views as an abstraction layer.
Build some sort of data warehouse
platform and write an ETL process to
populate it from the various data sources. This is more flexible but more effort to build and it will only work from a periodic refresh. If that degree of latency is acceptable for your application then I would suggest that the data warehouse system is the better approach.
The key advantage of a data warehouse is that it is optimised for reporting and has a consistent interface across all the data sources - you consolidate them into a single database with one schema. The reports are developed against that schema. Adding new systems is achieved by writing an ETL process to populate the warehouse; the reports continue to work regardless of the data source.
WCF is a network communication system. You will find that it difficult to make this sort of architecture handle large volumes of data on a transaction by transaction basis - a batch loading ETL process would be much more efficient. However, if you need a real-time feed (perhaps for a trading floor system) you might be able to do it with something like this.
If you nead a low latency feed another approach would be to investigate a genre of tooling called Enterprise Information Integration. Perhaps the most widely available tool that can do this is a Data Source View in SSIS which does give you some flexibility in mapping arbitrary data sources to a consistent schema. It isn't as sophisticated as the best of breed EII tools but you can put SSIS packages on top of it and use those as a data source for your reports if you need to further transform the data.
However, I've never built a system structured like this so I can't really vouch for how well it works in practice. I would guess that it would be quite fragile and difficult to break down into parts that can be unit tested, so development and maintenance will be quite time-consuming for a system of non-trivial complexity.
If you want to investigate other EII systems on the market This link is a directory of various articles about EII and some other EII tooling vendors.
我同意 NXC 的数据仓库建议：
因此，您需要使用这种方法进行 ETL - 一种选择是执行某种形式的 ROLAP，但在实践中，我发现编写 ETL 脚本就像从 ROLAP 设置中获得良好的性能一样容易。
I agree with NXC's data warehouse suggestion:
So, you are required to do ETL with this approach - one option is to do some form of ROLAP, but in practice I have found it to be as easy to write ETL scripts as it is to cajole good performance out of a ROLAP setup.
我认为通常会在后面咬你一口的答案是从每个数据库生成 XML 数据，但我认识的其他人也喜欢这个答案。 这为您提供了一组一致的数据，其形式大多数产品都可以轻松处理。
如果您这样做，请确保您将在其上运行的 XPath 查询速度很快。
An answer that I think will generally come back to bite you in the rear, but that others I know like, is to produce the data as XML from each database. That gives you a consistent set of data in a form that most products can easily handle.
If you do this, make sure that the XPath queries you will run on it will be fast.