在SQL Server Integration Services(SSIS)中，可以建立与平面文件的连接，该文件可以保存数百万条记录并将该数据推入SQL DB。此外，可以通过引用和使用Microsoft.SqlServer.Dts.Runtime命名空间从Capp调用此过程。

是最好使用SSIS运行具有数百万条记录的平面文件，还是集体"我们"希望使用具有多个工作线程的capp(一个用于读取并将行添加到变量，一个用于将该行写入该变量到数据库)，还有一个管理这些线程的"母亲"类？ (开发箱中有两个cpu)

我已经看到了此数据(sql团队博客)，它表明对于具有一百万行的平面文件来说，SSIS是最快的：

Process                Duration (ms)
--------------------   -------------
SSIS - FastParse ON         7322 ms 
SSIS - FastParse OFF        8387 ms 
Bulk Insert                10534 ms 
OpenRowset                 10687 ms 
BCP                        14922 ms

你觉得呢？你有没有什么想法？

解决方案

SSIS的速度非常快。此外，如果需要重复进行某些操作，则可以设置代理以按计划将其启动。自己编写是一回事，尝试使其成为多线程比最初看起来要复杂得多。

我建议SSIS十分之九。

我只能为自己和我的经历说话。我会选择SSIS，因为这是我们可能不必要地重新发明轮子的情况之一。这是SSIS已解决的重复性任务。

我每天管理约57个工作(DTS和SSIS的组合)。其中有四个通常处理5至1亿条记录之间的导出。我管理的数据库大约有20亿行。我利用脚本任务将日期添加到毫秒以下，这样我一天就可以运行几次作业。现在已经做了大约22个月了。太好了！

SSIS作业也可以安排。因此，我们可以设置它而忘记它。我每天都会监视所有内容，但是文件处理部分从未发生故障。

我唯一必须求助于自定义C程序的时间是当我需要将非常大的文件拆分为较小的块时。 SSIS对于这种东西实在太慢了。使用脚本任务，一个gig的文本文件花了大约一个小时来拆分。 Ccustom程序在12分钟内处理了该问题。

最后，只要使用我们觉得舒服的东西即可。

在这种情况下，我看不到使用多个线程如何帮助提高性能。传输大量数据时，主要瓶颈通常是磁盘I / O。产生多个线程并不能解决这个问题，我猜这将使情况变得更糟，因为它将在命中数据库的多个进程之间引入锁定争用。