.Net vs SSIS：SSIS应该用于什么？
如果我有使用.Net的选项，并且可以在.Net中进行数据转换，那么我什么时候需要SSIS？ SSIS会更好吗？ 透明度的附加好处值得吗？ 这只是我更舒服吗？ 确定这个的最佳实践是什么？
好问题。
如果数据传输量巨大？ 你正在处理多个数据文件，并需要交易（在文件系统级别和数据库级别）？ 你在不同的位置处理多个数据源（例如，ftp，本地文件系统，数据库）？
如果上面的答案是肯定的，那么继续ssis。 基本上.net对于小数据导入/导出工作很酷，但是当你有更复杂的东西时，ssis是一个明确的赢家
另一件我看到的是 – 当ssis中有一切可用的时候，值得写.net代码。 （不要误会我 – 我喜欢编码）但是，任何你编码，你需要保持:-)
我认为项目时间/预算限制以及标准工具的使用是使用SSIS的一些最重要的参数。 创build一个SSIS包大部分时间比在.NET中编写类似代码更快。
但有了这个说法，似乎SSIS有很多痛点 ，有时可能会使这个论点无效。 它为我开发了一个需要在不同的环境下运行的解决scheme。 SSIS看起来太痛苦了，我对这个项目的评价越多。 一个适当架构的.NET解决scheme更容易部署，更可靠，更灵活，更容易理解，也可以实现非常好的性能。
恕我直言：考虑使用SSIS的项目，你只需要部署到一个或两个内部的SQL Server环境。 否则，.NET方法将很快变得更具吸引力。
我想这取决于你在做什么。 SSIS非常强大，就像老式的DTS一样。 如果你正在加载大量的项目，并期望有不断的变化，我会一直去SSIS。 如果你正在寻找只加载几个项目，这是很多客户，我会把它放在代码中。 我更喜欢在内部ETL过程中使用SSIS，但是当我需要从传统系统将数据加载到SQL数据库时，我在客户端使用.Net。 现在，正如我之前所说，如果你有很多转换和许多不同的数据孤岛加载，我想你会疯狂在.Net做这个，我会去SSIS。 如果你只有一些项目需要加载，而且是单个应用程序，并且可能作为应用程序的一部分安装在不同的客户端上，我会一路去.Net。 只是我2美分。
从小项目到大型，复杂的ETL，我有很多SSIS的经验。 没有深入细节，这是我对你的指导：
-
如果你是一个DBA，并且你不熟悉.NET，或者你是一个熟悉SSIS的开发者，那么你可以使用SSIS来进行一些简单，相当简单的提取，转换，加载（ETL）任务。
-
SSIS非常古怪，还有许多陷阱，陷阱和可能被认为是直接的错误。 如果你非常熟悉，这是非常强大的。
-
C＃现在有TPL数据stream。 简单的性能testing让它领先于SSIS。 （例如http://mymemoryleaks.blogspot.cz/2013/10/ssis-vs-tpldataflow.html ）
-
如果你想做的事情不是微不足道的，而且如果你可以使用.NET的技能，使用.NET而不是SSIS。
SSIS有许多内置的方法可以从不同的数据源进行转换，您可以将它们串联在一起，使其非常具有可定制性。 他们已经build立了优化，使他们快速。
您还可以使用.NET进行自定义转换，以利用SSIS作业的速度和可重复性。
我不使用SSIS的理由是：
-
devise绿地产品，使他们拥有RESTful数据源，用于项目计划和预算内置的报告和提取，最好是OData等标准，以便其他工具可以直接插入。
-
数据馈送应该从上游系统拉动并转换，并按需提供; 这样计划任务，计划任务的configuration，任务运行者虚拟机和员工运行所有这些不可靠的调度的东西被否定。
-
RESTful数据提要利用HTTPcaching。
-
Feeds / services / API可以轻松移动到弹性云端。
-
SSIS要求find具有SSIS技能的人员，他们可以享受几周的时间。 根据我的经验，find并保留SSIS开发者是困难和昂贵的，发现的人往往是低于标准的。
-
SSIS在源代码控制和协同工作方面效果不佳。
-
与微服务和传统代码库不同，SSIS不适合代码重用。
-
与REST服务不同，SSIS不易于版本化。
-
SSIS不适用于模块化devise和许多小的变化的持续部署，它往往是大批量和可怕的版本。
-
SSIS推动使用存储过程，这对于热点地区的SQL提出了很多需求。 喜欢devise的地方要求可扩展，无状态的中间层。
-
工具笨重，不可靠。
-
你是微软SSIS路线图的摆布。
-
考虑在数据进入应用程序后尽快写入支持分析，报告和视图的表/服务; 请参阅CQRS和其他应用程序体系结构模式。
-
切勿使用Excel作为数据源 ; 培训员工。
-
代码是国王。
最终，我将SSIS看作企业IT的遗迹。 我想问一下，“Google会使用SSIS吗？ 如何解决问题呢？ 创造性思考。
我认为主要优点是直观地定义整个编程结构。 任何一个看SSIS包都是非常自我解释的。 与SQL的SSIS紧密集成使您可以成为SQL的一部分，用于备份调度和巨大的优势。
正如每个人所解释的，如果你正在做大量的数据操作，这是一个很好的工具。 如果你拥有SQL，那么你可以免费使用VS 2008 BIDS
有点迟到回答这个问题，但我希望它值得，
与编程语言相比，SSIS经常被误解。 SSIS是一个框架，而C＃是.NET Framework上的一种语言。 我在使用（MSBI套件）处理和开发大型数据仓库解决scheme方面拥有丰富的经验，并且还开发了大型网站（ASP.NET） – 所以我不能偏颇。
如果SSIS使用不当，可能会降低性能。 SSIS包有三种转换：
- 阻塞转换 – 只有在完成上述转换后才能传递数据，并获取所有行并完成所需的计算。
- 半块转换 – 可以传递部分数据
- 非阻塞 – 一旦准备就绪即可处理该行
SSIS在非阻塞转换的情况下工作得非常好，控制stream和数据stream的设置都是正确的。 我已经在更大的（超过2TB的数据仓库）上使用它，我可以保证这是最快的负载体验。 你可以用SSIS在30分钟内检查微博客的“ 我们装载1TB”，你也可以
我同意SSIS在处理阻塞转换时降低了性能，并且在需要时应该由T-SQL执行。
来到C＃，我接受SSIS使用.NET框架和数据提供者来完成任务。 但是，作为一种语言，C＃更合乎逻辑，必须处理好处理业务逻辑。 例如，如果我们必须根据条件运行不同的参数，则可以编写一个将考虑参数的包，然后在逻辑上决定运行一个exe文件需要传递哪个参数。 在SSIS中这样做会很漫长，而我可以在C＃中轻松完成，因为逻辑上的事情可以用语言而不是框架轻松完成。
现在这里的重点是解决你的问题陈述的更方便的方法。 SSIS是一个肯定的赢家，加载大量的logging从源代码到目的地加载数据，而C＃是完美的写逻辑。 即使您喜欢C＃，我也不build议您select在大型数据仓库系统上执行ETL（提取转换加载）操作。
