.Net vs SSIS:SSIS应该用于什么？

如果我可以选择使用.Net并且可以在.Net中进行数据转换,我何时需要SSIS？是否有一项SSIS会更好的任务？透明度的额外好处值得吗？这是我更舒服的吗？确定这个的最佳做法是什么？

好问题.

如果数据传输量巨大？你在处理多个数据文件并需要事务(在文件系统级别和数据库级别)？你在不同的位置处理多个数据源(例如ftp,本地文件系统,数据库)？

如果上面的答案是肯定的,那么继续进行ssis.基本上.net很酷,有小型数据导入/导出工作,但是当你有更复杂的东西时,ssis肯定是赢家

我看到的另一件事是 - 当ssis中的所有内容都可用时,是否值得编写.net代码.(不要误会我 - 我喜欢编码)但是,你编码的任何东西,你需要维护:-)

我认为项目时间/预算限制以及标准工具的使用是使用SSIS的一些最重要的论据.创建SSIS包大多数时候比尝试在.NET中编写类似代码的方式更快.

但话虽如此,似乎SSIS有很多痛点,有时可能会使这一论点无效.在开发需要在许多不同客户端的不同环境中运行的解决方案时,它确实为我做了.我对项目进行评估的次数越来越多,SSIS看起来太痛苦了.正确构建的.NET解决方案更易于部署,更可靠,更灵活,更易于理解,并且还可以实现非常好的性能.

恕我直言:考虑将SSIS用于您只需部署到一个或两个内部SQL Server环境的项目.否则,.NET方法将很快变得更具吸引力.

我不使用SSIS的论点是:

设计绿地产品,使其具有RESTful数据源,用于项目计划和预算中内置的报告和提取,最好是OData等标准,以便其他工具可以直接插入.

数据馈送应从上游系统中提取和转换,并按需提供; 这样,计划任务,计划任务的配置,任务运行者VM和运行所有这些不可靠调度的人员被否定.

RESTful数据源利用HTTP缓存.

可以轻松地将源/服务/ API移动到弹性云.

SSIS需要找到具有SSIS技能的人,他们喜欢这样做几周.根据我的经验,寻找和保留SSIS开发人员既困难又昂贵,而且人们发现这一点往往低于标准.

SSIS在源代码控制和协作工作方面效果不佳.

与微服务和传统代码库不同,SSIS不适合代码重用.

与REST服务不同,SSIS不易编辑.

SSIS不适用于模块化设计和许多小变更的持续部署,它往往是大批量的可怕版本.

SSIS促进了存储过程的使用,这对SQL是一个热点需求很大.赞成对可扩展的无状态中间层提出要求的设计.

工具笨重且不可靠.

你受微软SSIS路线图的支配.

一旦数据进入应用程序,请考虑写入支持分析,报告和视图的表/服务; 请参阅CQRS和其他应用程序架构模式.

切勿将Excel用作数据源 ; 培训员工.

代码是王道.

最终,我将SSIS视为企业IT的遗留物.我想问,"谷歌会使用SSIS吗？" 问题怎么解决？创造性思考.

我想这取决于你在做什么.SSIS非常强大,就像旧的DTS一样.如果你正在装载很多物品并期望不断变化,我会一路走SSIS.如果您只想加载一些商品并且它适用于许多客户,我会把它放在代码中.我更喜欢SSIS用于内部ETL过程,但是当我需要将遗留系统中的数据加载到SQL数据库时,我在客户端商店使用.Net.现在正如我之前所说,如果你有很多转换和许多不同的数据孤岛需要加载,我想你会疯狂地在.Net中这样做,我会去SSIS.如果您只有几个要加载的项目,并且它适用于单个应用程序,并且可以作为应用程序的一部分安装在不同的客户端,我会一直使用.Net.只需2美分.