作为一名.NET开发人员,为什么我应该更喜欢SSIS包而不是编写代码?在我目前工作的地方,我们有一大堆包在生产中,它们都是“写”的噩梦(也许是绘图?)并保持。每个包看起来就像一碗五颜六色的意大利面,在抽象崩溃的地方混合了C#和VB.NET脚本。为了弄清楚每个"Execute SQL Task“或"Foreach Loop”都做了什么,我必须双击这个该死的东西,浏览散布在多个选项卡中的文字值和表达式树。
我思想开放,所以我想知道是否有其他优秀的开发人员发现SSIS比仅仅编写一些代码更有效率。如果您确实发现SSIS更有效率,请告诉我为什么。
发布于 2010-08-25 00:14:42
我尝试过几次SSIS,但都放弃了。在C#中只做我需要的事情要容易得多。SSIS太复杂了,它有太多的陷阱,这是不值得的。把更多的时间花在提高C#技能上要比花同样多的时间学习SSIS要好得多-你会从你的培训中获得更多的回报。
此外,在VS解决方案中查找和维护功能也变得非常容易。使用VS进行单元测试很容易。我所需要做的就是在Subversion中签入源代码,并验证它是如何加载的。温和地说,SSIS包的单元测试是非常复杂的。
此外,在某些情况下,SSIS无法填充某些行中的某些列,只是跳过它们而不引发异常。我们花了很多时间排除故障,弄清楚到底是怎么回事。用C#开发一个替代的解决方案只用了不到一个小时,并且两年来没有任何问题。
发布于 2010-08-24 23:40:46
在我看来- SSIS只用于ETL操作,不应该包含该作用域之外的逻辑。
发布于 2010-08-24 23:51:26
我有一个不幸的经历,在一个项目中,我们认为SSIS将是一个足够好的解决方案,可以聚合和组合来自多个来源的数据。不幸的是,它一开始工作得很好,但后来需求发生了变化,我们(最终)意识到它是错误的工具。
也许我们只是不正确地使用了它,但是如果我们改变了我们的模式,我们就会遇到很多困难,最终我们只是重用了前端的ORM定义,用C#编写了一个自定义工具来完成这项工作。因为我们已经有了数据模型,所以这非常简单。显然,YMMV和我都不是SSIS专家,但在这种情况下,SSIS造成了很多重复的工作和令人头疼的事情,因为只是卷起袖子‘手工编码’它比预期的要容易。
因此,在考虑SSIS时,我会考虑很多灵活性。
https://stackoverflow.com/questions/3558185
复制相似问题