对于我们的报告应用程序，我们有一个每晚将多个数据库聚合到一个“报告”数据库中的过程。报告数据库的架构与我们正在聚合的单独“生产”数据库的架构完全不同，因此有大量业务逻辑涉及如何聚合数据。
现在这个过程是由几个每晚运行的存储过程实现的。随着我们向报告数据库添加更多详细信息，存储过程中的逻辑变得越来越脆弱和难以管理。
还有哪些其他策略可用于填充此报告数据库？
- SSIS？这已被考虑但似乎没有提供比存储过程更清洁、更易于维护的方法。
- 一个单独的 C#(或任何语言)进程来聚合内存中的数据，然后将其推送到报告数据库中？这将使我们能够为逻辑编写单元测试并以更易于维护的方式组织代码。
我正在寻找关于上述内容的任何新想法或其他想法。谢谢!
最佳答案
我们的一般流程是:
- 将源表中的数据复制到 与完全相同的表 加载数据库中的结构
- 将数据转化为暂存数据 表，具有相同的结构 作为最终的事实/维度表
- 将临时表中的数据复制到 事实/维度表
SSIS 适用于第 1 步，它或多或少是 1:1 的复制过程，具有一些基本的数据类型映射和字符串转换。
对于第 2 步，我们混合使用存储过程、.NET 和 Python。大多数逻辑都在过程中，在外部代码中进行大量解析。纯 TSQL 的主要好处是转换通常依赖于加载数据库中的其他数据，例如在 SQL JOIN 中使用映射表比在外部脚本中进行逐行查找过程要快得多，即使使用缓存也是如此。诚然，这只是我的经验，程序处理可能更适合您的数据集。
在少数情况下，我们确实需要进行一些复杂的解析(DNA 序列)，而 TSQL 并不是一个可行的解决方案。这就是我们使用外部 .NET 或 Python 代码来完成工作的地方。我想我们可以在 .NET 过程/函数中完成这一切并将其保存在数据库中，但还需要其他外部连接，因此单独的程序是有意义的。
第 3 步是一系列 INSERT...SELECT... 语句:速度很快。
总而言之，使用最好的工具来完成工作，不要担心混淆。 SSIS 包(或多个包)是将存储过程、可执行文件和您需要执行的任何其他操作链接在一起的好方法，因此您可以在一个地方设计、执行和记录整个加载过程。如果这是一个巨大的过程，您可以使用子包。
我知道你说 TSQL 感觉笨拙的意思(实际上，我发现它比其他任何东西都更重复)，但它对于数据驱动的操作来说非常非常快。所以我的感觉是，在TSQL中做数据处理，在外部代码中进行字符串处理或其他复杂操作。
关于database - 填充报告/数据仓库数据库的策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2007082/