Здравствуйте,
Объясняю ситуацию.
Из БД в таблицу (grid) считывается несколько сот записей (до полутысячи), пользователь изменяет их, после чего изменения должны записаться в БД. Т.к. между запиясми трудно найти что-то общее чтобы подогнать изменения под один запрос, то я так понимаю что мне придется делать несколько сот запросов к БД. Однако скорость выполнения запроса оставляет желать лучшего. Один запрос типа OleDbCommand->Execute...() выполняется порядка 2мс, что при большом количестве запросов выливается в секундную задержку. Я не знаю большая ли это задержка для одного запроса или нет, однако при большом количестве запросов такая скорость не устраивает. Поэтому вопрос: можно ли как-то уменьшить количество запросов к БД. Может есть какие-то средства для этого? Всмысле типа может можно все данные сначала записать куда-нибудь, откуда они потом бы одним запросов или просто как-то оптимально и быстро записались бы в БД?

Если надо я приведу примеры записей из таблицы в БД, а так же напишу какие действия с ними я произвожу.

Использую ADO .NET, работаю через OLEDB в соединенном режиме c Access базой посредством SQL-запросов (это так на всякий случай) =)

Надеюсь кто-то подскажет выход из ситуации. Спасибо

Я конечно не понял что за пользователь такой который изменяет несколько сот рекордов за секунду но не вдаваясь в подробности дам несколько советов.

1. Один SQL Update который изменяет 100 записей исполняется быстрее чем 100 разных Updates.
2. Есть операция Union которая может вернуть похожие по струтуре рекорды из разных таблиц за один запрос.
3. Можно испольщовать возможности NextRecordset то есть написать несколько SQL statements в один запрос. Правда кажется это в Акксесе нельзя делать.

George.

А>Я конечно не понял что за пользователь такой который изменяет несколько сот рекордов за секунду
— Я такого не говорил.

А>1. Один SQL Update который изменяет 100 записей исполняется быстрее чем 100 разных Updates.
— Это понятно в общем-то... Но я и спрашиваю потому-что не знаю иного выхода кроме как делать 100 разных UPDATE...

А>2. Есть операция Union которая может вернуть похожие по струтуре рекорды из разных таблиц за один запрос.
В моем случае Union никак не поможет.

А>3. Можно испольщовать возможности NextRecordset то есть написать несколько SQL statements в один запрос. Правда кажется это в Акксесе нельзя делать.
Да, Access не возвращает множественные результаты.

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

MC>Надеюсь кто-то подскажет выход из ситуации. Спасибо

Может выполнять запросы асинхронно? Создастся видимость мгновенного сохранения.
Однако возникнут другие проблемы.

"MozgC" <34572@users.rsdn.ru> schrieb im Newsbeitrag news:1055068@news.rsdn.ru...
...
> Использую ADO .NET, работаю через OLEDB в соединенном режиме c Access базой посредством SQL-запросов (это так на всякий случай) =)
>
> Надеюсь кто-то подскажет выход из ситуации. Спасибо

Выход я вижи в применении MSDE и DTS.

Peter

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

MC>Здравствуйте,
MC>Объясняю ситуацию.
MC>Из БД в таблицу (grid) считывается несколько сот записей (до полутысячи), пользователь изменяет их, после чего изменения должны записаться в БД. Т.к. между запиясми трудно найти что-то общее чтобы подогнать изменения под один запрос, то я так понимаю что мне придется делать несколько сот запросов к БД. Однако скорость выполнения запроса оставляет желать лучшего. Один запрос типа OleDbCommand->Execute...() выполняется порядка 2мс, что при большом количестве запросов выливается в секундную задержку. Я не знаю большая ли это задержка для одного запроса или нет, однако при большом количестве запросов такая скорость не устраивает. Поэтому вопрос: можно ли как-то уменьшить количество запросов к БД. Может есть какие-то средства для этого? Всмысле типа может можно все данные сначала записать куда-нибудь, откуда они потом бы одним запросов или просто как-то оптимально и быстро записались бы в БД?

MC>Если надо я приведу примеры записей из таблицы в БД, а так же напишу какие действия с ними я произвожу.

MC>Использую ADO .NET, работаю через OLEDB в соединенном режиме c Access базой посредством SQL-запросов (это так на всякий случай) =)

MC>Надеюсь кто-то подскажет выход из ситуации. Спасибо

не знаю насколько это поможет — была у меня похожая проблема. решил я её достаточно просто — для всех изменений которые делал юзер с таблицей велось протоколиорвание(сюда же облокотилось и Undo/Redo — можно юзать паттерн Команда), так вот, перед тем как вкатывать транзакцию, я оптимизировал тот самый вектор изменений юзера — то есть:
1. stable_sort. стабильная сортировка — на каждую запись, которую юзер как-то изменял получался непрерывный интервал его изменений с сохраненем послдеовательности действий. тут собственно важно что сортировка должна быть стабильной — чтобы не нарущить порядок действий юзера.
2. ну и берем оттуда по одному интервалу изменеий(equal_range) на каждую запись, и применияем её:
— было удаление — смертельно для записи — для неё делаем тока ДЕЛЕТЕ запрос
— остальные изменения по порядку накатываем на запись — все изменения накатили, формируем один ИНСЕРТ запрос, который уже имеет все изменения( для существующих записей я их правил прямо через рекордсет, но опять же главное что один раз — когда я открывал рекордсет чтобы его пропатчить — все изменения были уже готовы )

по итогу имеет набор запросов — по одному на каждую измененную юзером запись. у меня работало замечательно на 5К записей, даже при том, что поддерживался совместный доступ юзеров к БД и нужно было еще уметь по ходу определять конфликты — то есть редактирование удалённых в другом сеансе записей и т.д. да, и я к каждой записи в БД прикрутил по гуиду — чтобы не париться с уникальными ключами и прочей неудобной еруной. получилось на один столбец больше, но объём БД у меня был не критичен и производительность была очень даже ничего...
но решение архитектурное — такое малой кровью в проект не всунешь — просто прикинь что и как — может натолкнёт на мысль... удачи.

MC>Здравствуйте,
MC>Объясняю ситуацию.
MC>Из БД в таблицу (grid) считывается несколько сот записей (до полутысячи), пользователь изменяет их, после чего изменения должны записаться в БД. Т.к. между запиясми трудно найти что-то общее чтобы подогнать изменения под один запрос,


гм. Юзер изменил запись, нажал Ok, запись тутже сохранилась
открыл новую запись для редакирования, изменил, нажал Ok, запись тутже сохранилась
.....

Каждая позиция редактирования сохраняется сразу после редактирования.

У меня так все работает, 0 проблемм.

Зачем изменять записи всем скопом через определенное время? а может за это время их уже кто-то поменял? и там другие данные.

запрос 2mc нормальное время на Update (смотря конечно какой сервер.)

Мои мысли:
1. Подумать о более серьезной базе данных (например SQL Server).
2. Для Вашей задачи идеально подходит связка
.Net <> XML <> OPENXML/XPATH <> SQL SERVER
3. При хорошей настройке XML дает значительные преимущества в скорости, появляется возможность выполнять фильдиперсовые апдейты.
4. Сохраняйте изменения по факту. У меня сохраняется при перемещении на следующую строку грида и ничего не затыкается
5. Может все-таки есть какой-то инвариант? Попробуйте все-таки пересмотреть архитектуру... Может даже ценой избыточности получится достичь универсальности.
ЗЫ Если честно я даже задачу такую придумать не могу
Просто интересно что Вы делаете.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

В общем ситуация была такая.
Есть таблица Parts
В таблице находится информация о заказанных запчастях. Так же в этой таблице есть 5 полей Supplier1 — Supplier5, которые хранят информацию о том, каким поставщикам ушел заказ на данную запчасть.
В форме создания заказа поставщику пользователь выбирал по нужному фильтру запчасти (обычно несколько сот штук), после чего выбирал какому поставщику отправить заказ на эти запчасти и нажимал кнопку Generate. При это создавался excel файл заказа поставщику а в БД должна записаться информация о том какие запчасти отосланы выбранному поставшику. Если бы все было только так, то можно было бы только производить запись в БД (апдейтить записи с нужными ID), но нужно решить в какое поле записать поставщика. Если заказ уже отсылался одному поставшику, то нового поставшика надо записать уже не в поле Supplier1 а в поле Supplier2. Поэтому для каждой из нескольких сот записей я думал считать информацию о поставщиках из БД, проанализировать и в зависимости от этого потом делать опять же несколько сот запросов UPDATE записывая выбранного поставщика в нужное поле (Supplier1 — Supplier5). В сумме вообще получалось очень много запросов.

Оптмизацию провел в 2 этапа.

Во-первых, избавился от необходимости несколько сот раз считывать из БД информацию о поставщиках каждой записи путем считывания этой информации одним запросом на этапе заполнения грида (т.е. в гриде делаю невидимыми поля Supplier1 — Supplier5, считывю их вместе с остальными полями в 1 запросе, после чего анализирую поставщиков уже в памяти, получая инфу о них из грида, а не сотнями запросов из БД).

Во-вторых, как подсказал Guderian, я использовал транзакцию при апдейте записей, т.е. типа того:

myTrans = CarDB::conn->BeginTransaction(IsolationLevel::ReadCommitted);
command->Transaction = myTrans;
...
myTrans->Commit();

В результате удалось получить 3х кратный выигрыш в скорости — засчет транзации скорость записи увеличилась на 40%, а засчет избавление от ненужных запросов на чтение информации о поставшиках общая скорость повысилась еще чуть более чем в 2 раза. Думаю неплохой результат.

Всем спасибо за участие и советы.

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

А>>Я конечно не понял что за пользователь такой который изменяет несколько сот рекордов за секунду
MC> — Я такого не говорил.
А я как бы и не говорил что говорили. Я пытался намекнуть на факт то что надо пересмотреть что-то в приложении. (Хотя не всегда это возможно)

А>>1. Один SQL Update который изменяет 100 записей исполняется быстрее чем 100 разных Updates.
MC> — Это понятно в общем-то... Но я и спрашиваю потому-что не знаю иного выхода кроме как делать 100 разных UPDATE...
Связи с тем что я не очень понял архитектуру я попытался сказать некоторые факты пусть и очевидные некоторым.

А>>2. Есть операция Union которая может вернуть похожие по струтуре рекорды из разных таблиц за один запрос.
MC>В моем случае Union никак не поможет.
Life tough

А>>3. Можно испольщовать возможности NextRecordset то есть написать несколько SQL statements в один запрос. Правда кажется это в Акксесе нельзя делать.
MC>Да, Access не возвращает множественные результаты.
Life tough

George.