Хранение в Sql Server 2005 данных большого объёма

[Guest]

Кто-нибудь пробовал хранить в SQL Server 2005 большие файлы? 50+Мб. Речь идёт об интерфейсе СУБД с C#, .NET.
Я использую для этого тип varbinary(MAX). Читать данные просто: можно сразу получить byte[], можно получить поток чтения (код на память не вспомню).
Проблема возникла с записью таких данных. Я могу в запрос подставлять простой массив byte[], но тут требуется весь большой файл загрузить в оперативку и запрос этот выполняется как-то непредсказуемо. Мне показалось из небольших тестов, что начиная с некоторого объёма данных, запись производится значительно дольше (20Мб = 3сек, 60Мб = 25сек). Для таких команд ещё приходится как-то выставлять разумный таймаут выполнения или убирать его вовсе. Как же можно большие данные записывать потоком? Есть ли другие предложения?

 

[Pasha]

Для: Димариус
Попробуй передавать stream в обертке

Ссылка скрыта от гостей

.

 

[Guest]

Попробую.
А как быть с таймаутами? Совсем убирать не хорошо, а выставишь минут 10 - может и не хватить во время повышенных нагрузок на сервер.

 

[NikSoft]

Для: Димариус
Быть может след ссылки подскажут направление

https://codeby.net/threads/9955.html
https://codeby.net/threads/9400.html

 

[Guest]

Не, я не про много маленьких записей, а про одну большую. Ну, скажем, в ячейке файл целый хранится.

С потоками всё работает. Только время записи интересное. Для файла на 60Мб проводил 10 экспериментов записи. Вот времена (сек): 18 21 10 11 9 5 6 5 ... Сначала долго, потом быстро. Интересно, как сделать так, чтобы сразу быстро

 

[pushkin]

А можно поинтересоваться, зачем хранить такие объемы данных в SQL базе? Нельзя ли в базе просто хранить пути к файлам?

 

[Guest]

Можно, но мы приняли решение хранить их в БД. Это проще, не надо заботиться о том, есть файл, нет, синхронизировать с записями в БД... Тем более у нас архитектура такая, что прога на одном сервере, а СУБД с рейдом на другом и там нет нетбиоса, чтобы файлы напрямую заливать.