Экспортируйте большие объемы данных клиенту в asp.net

You can respond to a page request with a file:

Response.AddHeader("Content-Disposition", 
    "attachment; filename=yourfile.csv");
Response.ContentType = "text/plain";

Be sure to turn buffering off, so IIS can start sending the first part of the file while you are building the second:

Response.BufferOutput = false;

After that, you can start writing the file like:

Response.Write("field1,field2,field3\r\n");

When the file is completely written, end the response, so ASP.NET doesn't append a web page to your file:

Response.End();

This way, you don't have to write files on your web servers, you just create the files in memory and send them to your users.

If compression is required, you can write a ZIP file in the same way. This is a nice free library to create ZIP files.

Ваш подход работает нормально. SSIS + 7zip может быть полезен для автоматизации процесса, если вам нужно сделать это более пары раз.

If XML is OK, one approach would be to select the data "FOR XML" like this: http://www.sqljunkies.ddj.com/Article/296D1B56-8BDD-4236-808F-E62CC1908C4E.scuk

And then spit out the raw XML directly to the browser as content-type: text/xml. Also be sure to set up Gzip compression on your web server for files with XML extensions. http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?mfr=true

This will shrink the XML file down to 1/3 or maybe 1/4 the size as it's transferred. This wouldn't be the highest performance option because of the inherent wasted space in XML files, but a lot depends on what format you're looking for in the end.

Another option would be to use the free CSharpZipLib to compress the XML (or whatever format you want) into a zip file that the user would download. Along those lines, if this is something that will be used frequently you might want to look into caching and storing the zip file on the web server with some sort of expiration so it's not regenerated for every single request.

The download link is a perfectly valid and reasonable solution. Another would be to automatically redirect the user to that file so they didn't need to click a link. It really depends on your workflow and UI experience.

I would suggest against implementing compression in the SQL Server engine. Instead look at the DotNetZip library (Or System.IO.Conpression if you think your users have the capability of uncompressing gzip archives) and implement the compression within the web application.

Я бы не стал связывать базу данных, ожидая, пока пользователь загрузит 100 МБ, даже для высокоскоростного пользователя. Когда пользователь запрашивает файл, попросите его указать адрес электронной почты. Затем вызовите асинхронный процесс, чтобы вытащить данные, записать их во временный файл (в конце концов, не хочу> 100 МБ в памяти), затем заархивируйте временный файл в место хранения, затем отправьте пользователю электронное письмо со ссылкой для загрузки файл.