blocks|key|1871524|text|SSIS不是一个程序。很多细节在SSIS中做得更快，作为管理员，您可以获得非常好的详细进度和错误信息-这在SSIS要解决的场景中可能非常好，因为有时事情会出错，管理员需要大量信息。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1871525|也就是说，如果你没有自我解释的东西，SSIS就不是那么有用--它们是有意义的，过多地投入到常规编程中会让它们变得很糟糕。|1871526|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

SSIS is not a program. A lot of thigns are faster to make in SSIS, and you get very nice detailed progress and error information as admin - which can be very good in the scenarios SSIS is meant to solve, because sometimes things go wrong and the admin needs a lot of information.

That being said, SSIS is not really that usefull if you dont have the stuff self edxplanatory - they are meant for something, getting too much into general programming makes them sucky.

blocks|key|1871530|text|在我看来-+SSIS只用于ETL操作，不应该包含该作用域之外的逻辑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1871531|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In my opinion - SSIS is for ETL operations only and should contain no logic outside that scope.

blocks|key|1871536|text|SSIS有它的位置，而这个位置不是通用编程或作为存储过程的替代。它来自ETL流派(提取、转换和加载)，这就是它的优点所在。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1871537|旧名称(DTS，Data+Transformation+Services)和新名称(SSIS，Sql+Server+Integration+Services)都表明它是一个服务(或一组服务)，旨在操作数据以将SQL+Server数据库集成到更大的进程中。|1871538|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

SSIS has its place, and that place is not general programming or as a replacement for stored procedures. It comes from the ETL school (Extract, Transform, and Load) and that's where its stregnth is. 

The old name (DTS, Data Transformation Services) and the new name (SSIS, Sql Server Integration Services) both make clear it's a service (or set of services) designed to manipulate data to integrate the SQL Server database into larger processes.

blocks|key|2085518|text|我有一个不幸的经历，在一个项目中，我们认为SSIS将是一个足够好的解决方案，可以聚合和组合来自多个来源的数据。不幸的是，它一开始工作得很好，但后来需求发生了变化，我们(最终)意识到它是错误的工具。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2085519|也许我们只是不正确地使用了它，但是如果我们改变了我们的模式，我们就会遇到很多困难，最终我们只是重用了前端的ORM定义，用C#编写了一个自定义工具来完成这项工作。因为我们已经有了数据模型，所以这非常简单。显然，YMMV和我都不是SSIS专家，但在这种情况下，SSIS造成了很多重复的工作和令人头疼的事情，因为只是卷起袖子‘手工编码’它比预期的要容易。|2085520|因此，在考虑SSIS时，我会考虑很多灵活性。|2085521|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I had the unfortunate experience of working on a project where we thought SSIS would be a good enough solution to aggregate and combine data from several sources. The unfortunate thing was that it worked great at first but then requirements changed and we (eventually) realized that it was the wrong tool. 

maybe we were just using it incorrectly but we had a lot of difficulty if we ever changed our schema and we eventually just reused our ORM definitions from the front end to write a custom tool in C# to do this. Because we already had the datamodel this was surprisingly easy. obviously YMMV and i am by no means an SSIS expert, but in this one case SSIS caused a lot of duplicate work and headaches when just rolling up our sleeves and 'handcoding' it was easier than expected.

So i would think about flexibility a lot when considering SSIS.

blocks|key|1871564|text|我尝试过几次SSIS，但都放弃了。在C#中只做我需要的事情要容易得多。SSIS太复杂了，它有太多的陷阱，这是不值得的。把更多的时间花在提高C#技能上要比花同样多的时间学习SSIS要好得多-你会从你的培训中获得更多的回报。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1871565|此外，在VS解决方案中查找和维护功能也变得非常容易。使用VS进行单元测试很容易。我所需要做的就是在Subversion中签入源代码，并验证它是如何加载的。温和地说，SSIS包的单元测试是非常复杂的。|1871566|此外，在某些情况下，SSIS无法填充某些行中的某些列，只是跳过它们而不引发异常。我们花了很多时间排除故障，弄清楚到底是怎么回事。用C#开发一个替代的解决方案只用了不到一个小时，并且两年来没有任何问题。|1871567|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I tried using SSIS several times, and gave up on it. IMO it is much easier to just do all I need in C#. SSIS is too complex, it has too many gotchas, and it is just not worth it. It is much better to spend more time on improving C# skills than to spend same time on learning SSIS - you'll get much more return on your training.

Also finding and maintaining functionality in a VS solution is so very much easier. Unit testing with VS is easy. All I need to do is to check in the source in Subversion, and verify how it loaded. Unit testing SSIS packages is very involved to put it mildly.

Besides, there were situations when SSIS was silently failing to populate some columns in some rows, just skipping them without raising exceptions. We spent a lot of time troubleshooting and figuring out what is going on. Developing an alternative solution in C# took less than an hour, and works without any problems for two years.

blocks|key|2085539|text|如果希望以编程方式移动数据，可能需要考虑Rhino+ETL。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2085540|我还在开发自己的框架Fluent+ETL，因为我发现SSIS太过复杂，无法完成与开发相关的简单数据任务，比如从CSV文件加载单元测试数据。|offset|length|2085541|entityMap|0|LINK|mutability|MUTABLE|url|http://fluentetl.codeplex.com/^0|0|A|A|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

If you want to move your data programmatically, you might want to look at Rhino ETL.

I'm also working on my own framework, <a href="http://fluentetl.codeplex.com/" rel="nofollow noreferrer">Fluent ETL</a>, as I find SSIS a bit too involved for simple data tasks related to development, like loading unit test data from a CSV file.

As a .NET developer, for what reasons should I prefer SSIS packages over writing code? We have a ton of packages in production where I currently work, and they're a nightmare to both "write" (perhaps draw?) and maintain. Each package looks like a bowl of multicolored spaghetti with C# and VB.NET scripts mixed in at the points where the abstractions break down. To figure out what each "Execute SQL Task" or "Foreach Loop" does, I have to double click the damned thing and browse through a tree of literal values and expressions, scattered across multiple tabs.

I'm open minded, so I'd like to know if any other good developers find SSIS more productive than just writing some code. If you do find SSIS more productive, please tell me why.

Should programmers use SSIS, and if so, why?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

作为一名.NET开发人员，为什么我应该更喜欢SSIS包而不是编写代码？在我目前工作的地方，我们有一大堆包在生产中，它们都是“写”的噩梦(也许是绘图？)并保持。每个包看起来就像一碗五颜六色的意大利面，在抽象崩溃的地方混合了C#和VB.NET脚本。为了弄清楚每个"Execute SQL Task“或"Foreach Loo...

问程序员应该使用SSIS吗?如果应该，为什么？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问程序员应该使用SSIS吗?如果应该，为什么？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问程序员应该使用SSIS吗?如果应该，为什么？
EN