如果我可以选择使用.Net 并且可以在.Net 中很好地处理数据transformations，我什么时候需要SSIS？ SSIS 是否有更好的任务？透明度带来的额外好处值得吗？这只是我更舒服的吗？确定这一点的最佳做法是什么？
【问题讨论】：
标签： .net sql-server ssis
好问题。
如果传输的数据量巨大？您是否正在处理多个数据文件并需要事务（在文件系统级别和数据库级别）？您是否在处理不同位置的多个数据源（例如 ftp、本地文件系统、数据库）？
如果上面的答案是肯定的，那么继续 ssis。基本上 .net 对小数据导入/导出工作很酷，但是当您有更复杂的事情时，ssis 绝对是赢家
我看到的另一件事是 - 当 ssis 中的所有内容都可用时，是否值得编写 .net 代码。 （不要误会我 - 我喜欢编码）但是，任何你编码的东西，你都需要维护 :-)
【讨论】：
我认为项目时间/预算限制和使用标准工具是使用 SSIS 的一些最大理由。大多数情况下，创建 SSIS 包比尝试在 .NET 中编写类似代码要快得多。
但话虽如此，SSIS 似乎有很多 pain points 有时可能会使这个论点无效。在开发需要在许多不同客户的不同环境中运行的解决方案时，它对我有用。我对项目的评估越多，SSIS 看起来就太痛苦了。正确架构的 .NET 解决方案更易于部署、更可靠、更灵活、更易于理解，并且还可以获得非常好的性能。
恕我直言：考虑将 SSIS 用于只需要部署到一个或两个内部 SQL Server 环境的项目。否则，.NET 方法将很快变得更具吸引力。
【讨论】：
我不使用 SSIS 的论点是：
设计新产品，使其具有 RESTful 数据馈送，用于报告和提取内置到项目计划和预算中，最好是像 OData 这样的标准，以便其他工具可以直接插入。
数据馈送应从上游系统和按需馈送中提取和转换；这样调度任务、调度任务的配置、任务运行器虚拟机和运行所有这些不可靠调度内容的人员都会被否定。
RESTful 数据馈送利用 HTTP 缓存。
Feeds/services/APIs 可以轻松迁移到弹性规模的云中。
SSIS 需要找到具有 SSIS 技能并喜欢在数周内从事这些工作的人。以我的经验，寻找和留住 SSIS 开发人员既困难又昂贵，而且找到的人往往低于标准。
SSIS 不适用于源代码控制和协作工作。
与微服务和传统代码库不同，SSIS 不适合代码重用。
与 REST 服务不同，SSIS 不容易版本化。
SSIS 不适合模块化设计和许多小更改的持续部署，它往往是大批量和可怕的版本。
SSIS 提倡使用存储过程，这对作为热点的 SQL 提出了很多要求。偏爱对可扩展、无状态的中间层提出要求的设计。
工具笨重且不可靠。
您受制于 Microsoft 的 SSIS 路线图。
考虑在数据进入应用程序后立即写入支持分析、报告和视图的表/服务；请参阅事件溯源和其他应用程序架构模式。
切勿将 Excel 用作数据来源；培训员工。
代码为王。
最终，我将 SSIS 视为企业 IT 的遗物。我想问，“Google 会使用 SSIS 吗？”还有什么办法可以解决这个问题？跳出框框思考。
【讨论】：
我想这取决于你在做什么。 SSIS 非常强大，就像旧的 DTS 一样。如果您要加载大量项目并期望不断变化，我会一直使用 SSIS。如果您只想加载几个项目并且它是为很多客户服务的，我会把它放在代码中。我更喜欢将 SSIS 用于内部 ETL 流程，但是当我需要将数据从遗留系统加载到 SQL 数据库中时，我会在客户商店使用 .Net。现在，正如我之前所说，如果你有很多转换和很多不同的数据孤岛要加载，我认为你在 .Net 中这样做会很疯狂，我会去 SSIS。如果您只有几个项目要加载，并且它用于单个应用程序并且可能作为应用程序的一部分安装在不同的客户端上，我会一直使用 .Net。只是我的 2 美分。
【讨论】：
我在 SSIS 方面拥有丰富的经验，从小型项目到大型复杂 ETL。不赘述，这是我给你的指导：
如果您是 DBA 并且不熟悉 .NET，或者如果您是非常熟悉 SSIS 的开发人员，那么您可以使用 SSIS 进行小型、简单、相当直接的提取、转换、加载（ETL ) 任务。
SSIS 非常古怪，有许多陷阱、陷阱和可能被视为彻底错误的东西。如果您非常熟悉，它会非常强大。
C# 现在具有 TPL 数据流。简单的性能测试使其领先于 SSIS。 （例如http://mymemoryleaks.blogspot.cz/2013/10/ssis-vs-tpldataflow.html）
如果您想做的事情不只是琐碎，并且如果您可以使用 .NET 技能，请使用 .NET 而不是 SSIS。
【讨论】：
SSIS 有许多内置方法可以从不同的数据源进行转换，您可以将它们串在一起，使其非常可定制。他们内置了优化功能，使其速度更快。
您还可以使用 .NET 进行自定义转换，以利用 SSIS 作业的速度和可重复性。
【讨论】：
我认为主要优点是可视化地定义整个编程结构。任何人看一下 SSIS 包都是自我解释器。与 SSIS 与 SQL 的紧密集成允许您成为 SQL 的一部分，以进行备份调度和巨大的优势。
正如每个人所解释的那样，如果您进行大量数据操作，它是一个很好的工具。如果你已经准备好使用 SQL 并且使用 VS 2008 BIDS 非常容易学习，它是免费的
【讨论】：
回答这个问题有点晚了，但我希望值得，
与编程语言相比，SSIS 经常被误解。 SSIS 是一个框架，而 C# 是 .NET Framework 上的一种语言。我在使用（MSBI 套件）处理和开发大型数据仓库解决方案方面拥有丰富的经验，并且还开发了大型网站（ASP.NET）——所以我不能有偏见。
如果使用不当，SSIS 会降低性能。 SSIS 包有三种转换：
SSIS 在控制流和数据流设置正确的情况下非常适合非阻塞转换。我已经在更大（超过 2 TB 的数据仓库）上使用它，我可以保证它是最快的加载体验。你可以查看微软博客We Loaded 1TB in 30 Minutes with SSIS, and So Can You
我同意 SSIS 在处理阻塞转换时会降低性能，并且它们应该在需要时由 T-SQL 承载。
来到 C#，我接受 SSIS 使用 .NET 框架和数据提供程序来完成任务。但是 C# 作为一门语言更符合逻辑，必须处理业务逻辑。例如，如果我们必须根据条件运行具有不同参数的 exe，您可以编写一个包，它会考虑参数，然后在逻辑上决定需要传递什么参数来运行一个 exe 文件。在 SSIS 中执行此操作将是一个漫长的过程，而我可以在 C# 中轻松执行此操作，因为逻辑的事情可以很容易地用语言而不是框架来完成。
现在这里的重点是解决您的问题陈述的更方便的方法。 SSIS 无疑是加载大量记录的赢家，将数据从源加载到目标，而 C# 非常适合编写逻辑。即使你喜欢 C#，我也不建议你选择在大型数据仓库系统上进行 ETL（Extract Transform Load）操作。
【讨论】：
SSIS 通常用于 ETL（Extract Transform Load）。具体用例是SSAS（SQL Server Analysis Services）多维数据集的预处理；并使用 Data Change Capture 增强提取功能。
它可以进行典型的自动化，包括 FTP 和电子邮件。有使用脚本任务（C# 或 Visual Basic）的编程方面，因此 SSIS 具有超出其包含控件的功能......
可以对包进行编程以使用条件控制流路径。例如，周一至周五执行某项任务，周六和周日执行不同的任务。或者在某些条件不满足的情况下拒绝执行 ETL。
SSIS 包可以调用其他 SSIS 包。这使代码保持模块化，允许重复使用。
它可以与各种数据源一起工作，并使用派生列控件执行简单的转换。这与在源服务器上进行转换（例如，可以是 Oracle 或 Hadoop - 您无法通过本地 SQL Server 控制的东西）进行转换。
【讨论】：
顾名思义，SSIS 是一个集成系统。在 .net 中处理连接到不同数据源（如 excel、teradata、oracle 等）的连接器以及履行正常关闭这些连接、垃圾收集、处理内存问题的责任可能非常困难。
因此，SSIS 是开箱即用的产品，非常适合以下场景：不仅需要从两个不同的来源提取数据，而且还需要在编写之前执行一系列查找、转换、合并、推导和计算它到目标位置（无论是 sql server、平面文件还是另一个数据库系统）。
SSIS 也有检查点，如果包由于任何原因失败，它将从停止的地方重新开始（需要对其进行配置，因为这不是默认行为）。
此外，SSIS 将为您节省大量时间，因为它的任务是可重用的，而且它的部署过程相当容易实施和安排，并得到出色的事件处理支持。
【讨论】：
基本上，SSIS 具有许多优点，例如将数据从 A 点传输到 B 点的更小的块中并单独调试它们，能够轻松访问 SQL Server 表，处理 XML 数据，使用 c# 脚本进行 API 调用以及将数据保存在 DB 中，读取远程服务器上的数据库数据和 FTP 等等。
除了一堆已经存在的 BI 块之外，您还可以使用自己的参数和输出创建自己的自定义任务。
希望我能够为已经存在的答案添加一些要点。
【讨论】：
日常任务，由 SSIS 开发人员使用并且是 与 .Net 相比相对容易，可以包含：
表格之间的数据比较。
Conditional Splitting，数据在某些基础上对数据进行阻塞 逻辑。
数据转换，查找，合并，联合，比较好用。
文件处理（修改、验证）。
错误处理，电子邮件警报。
容器，FOR/FOReach 循环很容易使用。
使用 WebService 任务很容易在 Web 服务上发布数据。
检查点，数据加载的可重新运行很容易处理。
在 ssis 中调试很容易 - 可以在容器杠杆、包上完成 级别。
如果任务不可用，也可以编写脚本。此外，您可以自定义自己的任务
【讨论】：
无论人们在以前的答案中说什么都是正确的，但我认为使用 SSIS 而不是编码的最重要方面是易于维护过程以及可重复使用的产品。
【讨论】：
SSIS 非常适合 BI 应用程序，您可以操作 Stage Table 上的数据，而不是使 DataWarehouse 表上的数据可用于 BI。
我可以连接到 SAP、Oracle 以获取员工信息并在 PowerBI、QlikView 等上可用...
如果您知道在哪里以及为什么使用它，它是一个很好的工具。使用 ir，因为它很酷，你会遇到麻烦。
【讨论】：