Доброго времени суток!

В хранимую процедуру требуется передать несколько стрингов и массив byte[], который может достигать 1 — 10 мБ. Слышал мнение, что при передаче через параметры хранимой процедуры работает медленно. Есть способ передавать параметры хранимой процеудуры через табличные переменные. Так можно существенно повысить скорость работы процедуры. Кто-нибудь понимает о чём идёт речь? Буду благодарен если поясните. Прошу прощения за отсутствие точной формулировки вопроса.
Заранее благодарен!

Здравствуйте, faa, Вы писали:

faa>Доброго времени суток!

faa>В хранимую процедуру требуется передать несколько стрингов и массив byte[], который может достигать 1 — 10 мБ. Слышал мнение, что при передаче через параметры хранимой процедуры работает медленно. Есть способ передавать параметры хранимой процеудуры через табличные переменные. Так можно существенно повысить скорость работы процедуры. Кто-нибудь понимает о чём идёт речь? Буду благодарен если поясните. Прошу прощения за отсутствие точной формулировки вопроса.
faa>Заранее благодарен!

А передать надо откуда? из другой процедуры или с клиента? Если из другой процедуры, то да, бывает быстрее сделать временную таблицу с большими данными, и использовать её.

Здравствуйте, Sshur, Вы писали:

S>Здравствуйте, faa, Вы писали:

faa>>Доброго времени суток!

faa>>В хранимую процедуру требуется передать несколько стрингов и массив byte[], который может достигать 1 — 10 мБ. Слышал мнение, что при передаче через параметры хранимой процедуры работает медленно. Есть способ передавать параметры хранимой процеудуры через табличные переменные. Так можно существенно повысить скорость работы процедуры. Кто-нибудь понимает о чём идёт речь? Буду благодарен если поясните. Прошу прощения за отсутствие точной формулировки вопроса.
faa>>Заранее благодарен!

S>А передать надо откуда? из другой процедуры или с клиента? Если из другой процедуры, то да, бывает быстрее сделать временную таблицу с большими данными, и использовать её.

Передать надо с клиента. Вставка данных в таблицу при помощи хранимой процедуры. Данные передаются через параметры хранимой процедуры от клиента на сервер.

Здравствуйте, faa, Вы писали:

faa>Передать надо с клиента. Вставка данных в таблицу при помощи хранимой процедуры. Данные передаются через параметры хранимой процедуры от клиента на сервер.

XML

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, faa, Вы писали:

faa>>Передать надо с клиента. Вставка данных в таблицу при помощи хранимой процедуры. Данные передаются через параметры хранимой процедуры от клиента на сервер.

А>XML

XML и быстро — понятия несовместимые

Здравствуйте, faa, Вы писали:


S>>А передать надо откуда? из другой процедуры или с клиента? Если из другой процедуры, то да, бывает быстрее сделать временную таблицу с большими данными, и использовать её.

faa>Передать надо с клиента. Вставка данных в таблицу при помощи хранимой процедуры. Данные передаются через параметры хранимой процедуры от клиента на сервер.

Тогда, как мне кажется, не будет разницы.

Здравствуйте, Sshur, Вы писали:

S>Здравствуйте, faa, Вы писали:


S>>>А передать надо откуда? из другой процедуры или с клиента? Если из другой процедуры, то да, бывает быстрее сделать временную таблицу с большими данными, и использовать её.

faa>>Передать надо с клиента. Вставка данных в таблицу при помощи хранимой процедуры. Данные передаются через параметры хранимой процедуры от клиента на сервер.

S>Тогда, как мне кажется, не будет разницы.

Немного прояснил, но не полностью...

Значит дело обстоит примерно так.

На сервере описывается пользовательский тип данных для параметра. Потом создаётся временная таблица и делается join. В итоге это быстрее чем передача параметров вызовом хранимой процедуры.
Как-то так...

Здравствуйте, faa, Вы писали:

faa>Есть способ передавать параметры хранимой процеудуры через табличные переменные. Так можно существенно повысить скорость работы процедуры. Кто-нибудь понимает о чём идёт речь?

В принципе, вам уже намекнули. Немного раскрою:
— объявляете в БД пользовательский табличный тип, у вас он будет содержать колонку типа varbinary для массива.
— в хранимку добавляете параметр такого типа
— на клиенте в качестве значения параметра используете DataTable со структурой, соответствующей табличному типу, и с одной записью, где и будет лежать ваш массив

Здравствуйте, faa, Вы писали:

faa>Доброго времени суток!

faa>В хранимую процедуру требуется передать несколько стрингов и массив byte[], который может достигать 1 — 10 мБ. Слышал мнение, что при передаче через параметры хранимой процедуры работает медленно. Есть способ передавать параметры хранимой процеудуры через табличные переменные. Так можно существенно повысить скорость работы процедуры. Кто-нибудь понимает о чём идёт речь? Буду благодарен если поясните. Прошу прощения за отсутствие точной формулировки вопроса.
faa>Заранее благодарен!

SqlBulkCopy во временную таблицу и использовать её из процедуры.
Это самый быстрый способ.

Здравствуйте, vmpire, Вы писали:

V>SqlBulkCopy во временную таблицу и использовать её из процедуры.
V>Это самый быстрый способ.

Для mssql.

Здравствуйте, faa, Вы писали:

faa>Слышал мнение, что при передаче через параметры хранимой процедуры работает медленно.

Зависит от конкретной СУБД, но да, обычно это не самый быстрый способ.

faa> Есть способ передавать параметры хранимой процеудуры через табличные переменные. Так можно существенно повысить скорость работы процедуры. Кто-нибудь понимает о чём идёт речь?

Если речь про mssql, то http://msdn.microsoft.com/en-us/library/bb510489.aspx , но версия сиквела должна быть довольно свежей. Если требуется поддержка более старых версий — самый быстрый способ это временная таблица + bulk insert. Если речь вообще не про mssql, то там будет все по своему.

Здравствуйте, Sshur, Вы писали:

S>XML и быстро — понятия несовместимые

Для Оракла это один из самых быстрых способов передачи большого объема структурированных данных.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Sshur, Вы писали:

S>>XML и быстро — понятия несовместимые

AVK>Для Оракла это один из самых быстрых способов передачи большого объема структурированных данных.

Да лан, неужели загнать в оракл xml на несколько мегабайт будет быстрее какого-то аналога BulkInsert?

Xml будет больше и по размеру и по нагрузке на проц во время парсинга.

Здравствуйте, Sshur, Вы писали:

S>Да лан, неужели загнать в оракл xml на несколько мегабайт будет быстрее какого-то аналога BulkInsert?

Какого именно аналога?

S>Xml будет больше и по размеру и по нагрузке на проц во время парсинга.

Про нагрузку на процессор от парсинга XML можно смело забыть, не тот порядок. А размер — обычно дело в локальной сети происходит, там это тоже не бутылочное горлышко. Учитывая неторопливость прочих операций общения с БД оверхед по ХМЛ обычно проблем не доставляет.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Sshur, Вы писали:

S>>Да лан, неужели загнать в оракл xml на несколько мегабайт будет быстрее какого-то аналога BulkInsert?

AVK>Какого именно аналога?

ну я не знаю, что именно используется в оракл для заливки большого количества данных, аналогично BulkInsert

S>>Xml будет больше и по размеру и по нагрузке на проц во время парсинга.

AVK>Про нагрузку на процессор от парсинга XML можно смело забыть, не тот порядок. А размер — обычно дело в локальной сети происходит, там это тоже не бутылочное горлышко. Учитывая неторопливость прочих операций общения с БД оверхед по ХМЛ обычно проблем не доставляет.

Странно, у меня другой опыт. Если нужно гонять данные фиксированной структуры, то xml неэффективно

Здравствуйте, AndrewVK, Вы писали:

V>>Это самый быстрый способ.
AVK>Для mssql.
Судя по вопросу, ТС имеет в виду именно MSSQL

Здравствуйте, Sshur, Вы писали:

AVK>>Про нагрузку на процессор от парсинга XML можно смело забыть, не тот порядок. А размер — обычно дело в локальной сети происходит, там это тоже не бутылочное горлышко. Учитывая неторопливость прочих операций общения с БД оверхед по ХМЛ обычно проблем не доставляет.
S>Странно, у меня другой опыт. Если нужно гонять данные фиксированной структуры, то xml неэффективно

Опыт гоняния данных в хранимки? Да даже если и без хранимок — XML и JSON весьма активно применяются для сетевого взаимодействия, если бы последствия по перформансу были бы настолько фатальны, как ты расписываешь, никто бы так не делал.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Sshur, Вы писали:

AVK>>>Про нагрузку на процессор от парсинга XML можно смело забыть, не тот порядок. А размер — обычно дело в локальной сети происходит, там это тоже не бутылочное горлышко. Учитывая неторопливость прочих операций общения с БД оверхед по ХМЛ обычно проблем не доставляет.
S>>Странно, у меня другой опыт. Если нужно гонять данные фиксированной структуры, то xml неэффективно

AVK>Опыт гоняния данных в хранимки? Да даже если и без хранимок — XML и JSON весьма активно применяются для сетевого взаимодействия, если бы последствия по перформансу были бы настолько фатальны, как ты расписываешь, никто бы так не делал.


Ну во-первых, json более эффективен, чем xml и именно его в основном гоняют в вебе

а во-вторых, речь шла все таки о субд

Здравствуйте, Sshur, Вы писали:

S>Ну во-первых, json более эффективен, чем xml

С точки зрения затрат на парсинг разницы нет, с точки зрения объема разница непринципиальна.

S>а во-вторых, речь шла все таки о субд

А в СУБД требования обычно мягче — редко кто СУБД по глобальным каналам таскает.