程序员应该使用SSIS吗？如果是，为什么？[关闭]

作为.NET开发人员，由于什么原因我应该比编写代码更喜欢SSIS包？我目前正在工作的工厂中有大量的软件包，它们既是“编写”（也许是平局？）和维护的噩梦。每个程序包看起来像一碗五彩的意大利面条，在抽象分解点混合了C＃和VB.NET脚本。为了弄清楚每个“ Execute SQL Task”或“ Foreach Loop”的作用，我必须双击该死的东西，并浏览散布在多个选项卡中的文字值和表达式树。

我态度开放，所以我想知道是否有其他优秀的开发人员发现SSIS比编写一些代码更有生产力。如果您发现SSIS更具生产力，请告诉我原因。

我每天都使用SSIS来维护和管理大型数据仓库和多维数据集。我从事商务智能和数据仓库工作已经两年了100％。在此之前，我是10的.NET应用程序开发人员。

SSIS的价值在于它是一种工作流引擎，可以将数据从一个位置移动到另一个位置，并且在此过程中可能会有一些有限的转换和条件分支。如果您的程序包包含大量脚本，则说明您的团队正在使用SSIS执行错误的任务，或者对SQL不满意或被炒作了。SSIS包很难调试。脚本组件绝对是一场噩梦，应仅用于格式化，循环播放或作为不得已的手段使用。

1. 使您的程序包保持简单，sql任务和数据流任务。
2. 在SSIS之外做尽可能多的工作，最好在SQL中做
3. 将变量保持在单个全局范围内
4. 将SQL保留在变量或存储过程中，永远不要内联
5. 将变量值保存在配置存储中，最好是SQL数据库

我尝试了几次使用SSIS，并放弃了。IMO可以轻松完成我在C＃中要做的所有事情。SSIS太复杂了，它有太多陷阱，这是不值得的。花更多的时间在提高C＃技能上比花更多的时间在学习SSIS上要好得多-您将获得更多的培训回报。

在VS解决方案中查找和维护功能也非常容易。使用VS进行单元测试很容易。我需要做的就是在Subversion中签入源代码，并验证其加载方式。温和地说，单元测试SSIS包非常复杂。

此外，在某些情况下，SSIS默默地未能填充某些行中的某些列，只是跳过它们而没有引发异常。我们花了很多时间进行故障排除并弄清楚发生了什么。用C＃开发替代解决方案用了不到一个小时的时间，并且两年来都没有出现问题。

我认为-SSIS仅用于ETL操作，并且不应包含超出该范围的逻辑。

我曾在一个项目上工作过，这很不幸，我们认为SSIS是一个很好的解决方案，可以汇总和合并来自多个来源的数据。不幸的是，起初效果很好，但随后需求发生了变化，我们（最终）意识到这是错误的工具。

也许我们只是错误地使用了它，但是如果我们更改了架构，就会遇到很多困难，最终我们只是从前端重用我们的ORM定义，以C＃编写自定义工具来执行此操作。因为我们已经有了数据模型，所以这非常容易。显然，YMMV和我绝不是SSIS专家，但是在这种情况下，SSIS只是卷起袖子并“手工编码”而引起许多重复的工作和令人头疼的事情，这比预期的要容易。

因此，在考虑SSIS时，我会考虑很多灵活性。

SSIS有它的位置，该位置不是通用编程或存储过程的替代品。它来自ETL学派（提取，转换和加载），这就是它的强大之处。

旧名称（DTS，数据转换服务）和新名称（SSIS，SQL Server集成服务）都清楚地表明这是一种旨在处理数据以将SQL Server数据库集成到更大进程中的服务（或一组服务）。

如果要以编程方式移动数据，则可能需要查看Rhino ETL。

我还在自己的框架Fluent ETL上工作，因为我发现SSIS对于与开发相关的简单数据任务过于投入，例如从CSV文件加载单元测试数据。

SSIS不是程序。在SSIS中，很多设计工作都变得更快，并且您以admin的身份获得了非常详细的进度和错误信息-在SSIS打算解决的情况下，这非常好，因为有时会出问题并且admin需要很多信息。

话虽如此，如果您没有自我规划的东西，那么SSIS并没有那么有用-它们是为某些目的而准备的，过多地参与常规编程会使它们变得很无聊。