data-warehouse – 避免在SSIS中完全编写SQL查询

前端之家收集整理的这篇文章主要介绍了data-warehouse – 避免在SSIS中完全编写SQL查询前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在数据仓库项目上工作,给我们教程的人建议我们坚持使用SQL查询而不是定义大量的数据流转换,引用它会在ETL盒子上消耗大量内存,所以我们而是将处理留给DB框.这真的可取吗?依赖GUI工具而不是在Integration包上执行一堆sql脚本之间的平衡点在哪里?

老实说,我想尽可能避免编写SQL查询. (但那不是重点.我真的很想客观地看待这一点.)

解决方法

答案是:它取决于,但你想为任何给定的工作选择一个或另一个,并避免在可能的情况下混合两个.

通常,最好在工具中尽一切可能,或在存储过程代码中尽一切可能.当您在层之间分配大量逻辑时,系统将变得更难以跟踪和调试.

>如果工具可以在没有数据流变得笨拙和复杂的情况下进行转换,您可以使用该工具并尝试在查询中使用很少或没有逻辑.这意味着一个单层具有业务逻辑,在哪里找到它应该相当明显.但是,ETL工具倾向于相对较差地处理高度复杂的转换.这种方法的最佳位置是在您拥有大量数据源但相对简单的转换的系统上.
>如果您有相对复杂的转换,最好将所有业务逻辑和转换放入一个存储过程层. sql代码更好地以可维护的方式实现复杂的转换 – 我有相当好的权限,银行和保险部门中大约一半的数据仓库项目正是出于这个原因使用这种类型的架构.在这种情况下,ETL工具可用于实现相对愚蠢的数据副本.源数据可以基本上逐字地复制到暂存区域,然后由执行ETL的存储过程代码的主体拾取. ETL工具可用于数据副本,批量加载操作,日志记录,调度和其他框架任务.

在任何一种情况下,你最好选择一种方法.否则,您最终可以在提取层,数据库视图,数据流和存储过程代码中分布业务逻辑.跨越多层的逻辑更难以测试.

当所有逻辑(例如)包含在存储过程或聚焦ETL转换作业中时,您可以单独测试给定转换.设计的清晰度也有助于维护和审计.

猜你在找的MsSQL相关文章