程序员应该使用SSIS，如果是的话，为什么？
作为一名.NET开发人员，出于什么原因，我宁愿使用SSIS包来编写代码？ 我们现在有很多包装在生产环境中，他们是一个“写”（也许是吸引）和维护的噩梦。 每个软件包看起来像一碗五彩的意大利细面条，C＃和VB.NET脚本混合在抽象的细节点上。 为了弄清楚每个“执行SQL任务”或“Foreach循环”所做的事情，我必须双击该死的东西，浏览遍布多个选项卡的文字值和expression式树。
我是开放的，所以我想知道是否有其他优秀的开发人员发现SSIS比编写代码更有效率。 如果你确实发现SSIS更有效率，请告诉我为什么。
我每天都使用SSIS来维护和pipe理一个大型数据仓库和多维数据集。 我一直是100％的商业智能和数据仓库两年。 在此之前，我是一名.NET应用程序开发人员。
SSIS的价值是作为一个工作stream引擎，将数据从一个地方移动到另一个地方，可能会进行一些有限的转换和条件分支。 如果你的软件包包含很多脚本，那么你的团队正在使用SSIS进行错误的任务，或者对SQL不太熟悉，或者大肆宣传。 SSIS包非常难以debugging。 脚本组件是一个绝对的噩梦，应该只用于格式化，循环，或作为最后的手段。
- 保持你的包简单，SQL任务和数据stream任务。
- 在SSIS之外尽可能多的工作，最好在SQL中
- 保持你的variables在一个单一的全球范围内
- 保持你的SQL在variables或存储过程中，从不在线
- 将你的variables值保存在configuration存储中，最好是SQL数据库
我尝试了几次使用SSIS，并放弃了它。 国际海事组织，只是做我需要在C＃中更容易。 SSIS太复杂了，它有太多的问题，只是不值得。 花更多的时间来提高C＃技能要比花同样的时间学习SSIS要好得多 – 你的培训将会获得更多的回报。
在VS解决scheme中查找和维护function也非常容易。 用VS进行unit testing很容易。 我所要做的就是检查Subversion中的源代码，并validation它是如何加载的。 unit testing的SSIS包是非常涉及到温和的。
此外，还有一些情况是SSIS在某些行默默无法填充某些列，只是跳过它们而没有提出exception。 我们花了很多时间进行故障排除，弄清楚发生了什么事情。 在C＃中开发替代解决scheme花了不到一个小时，两年内没有任何问题。
在我看来，SSIS只适用于ETL操作，不应该包含这个范围之外的逻辑。
我有一个不幸的经验，就是在一个项目上工作，我们认为SSIS是一个很好的解决scheme，可以汇总和合并来自多个来源的数据。 不幸的是，它起初工作得很好，但后来需求改变了，我们（最终）意识到这是错误的工具。
也许我们只是不正确地使用它，但是如果我们改变了模式，我们还有很多困难，最终我们只是重复使用了前端的ORM定义，在C＃中编写了一个自定义工具来做到这一点。 因为我们已经有了这个数据模型，所以这非常容易。 显然是YMMV，而我绝不是SSIS的专家，但是在这一个案例中，SSIS造成了很多重复的工作和头痛，只是卷起袖子，“手写”比预期更容易。
所以当考虑SSIS时，我会考虑灵活性。
SSIS有它的地方，那个地方不是一般的程序devise，或者是存储过程的替代。 它来自ETL学校（Extract，Transform和Load），这就是它的强项。
旧名称（DTS，数据转换服务）和新名称（SSIS，Sql服务器集成服务）都明确表示这是一个服务（或一组服务），旨在操纵数据以将SQL Server数据库集成到更大的进程中。
如果你想以编程方式移动你的数据，你可能想看看Rhino ETL。
我也在自己的框架Fluent ETL上工作 ，因为我发现SSIS涉及简单的与开发有关的数据任务，比如从CSV文件加载unit testing数据。
SSIS不是一个程序。 在SSIS中，很多行业的生产速度都很快，而且你可以很容易的获得详细的进度和错误信息 – 这在SSIS要解决的情况下是非常好的，因为有时候事情会出错，pipe理员需要很多信息。
也就是说，如果你没有自己的东西，那么SSIS并不是真的有用 – 它们是为了某种东西，对于一般的编程太过分了，这使得它们很糟糕。
