Показать сообщение отдельно
Старый 27.12.2006, 16:02   #6  
Oleksandr is offline
Oleksandr
Участник
Аватар для Oleksandr
 
68 / 17 (1) ++
Регистрация: 19.03.2005
Адрес: Киев
Цитата:
Сообщение от fomenka Посмотреть сообщение
Вы точно уверены в отсутствии возможности оптимизации вашего

while selecе a join b join c //возвращает под сотню тысяч записей.
{
while (bla bla ) // несколько повторов на одну запись
{
someoperation();
recordinsertlist.ins();
}
recordinsertlist.insertdatabse();
}
???

Как показывает опыт, проигрыш X++ по сравнению с чистым T-SQL конечно же бесспорный, но не настолько катастрофичный, что бы пренебречь высокоуровневой средой
Job - задача одного-двух использований? Тогда наверняка есть верхняя грань приемлемости времени выполнения Job'а. Не нужен 100% оптимальный результат, достаточно достичь указанной величины. Оптимизируя 20% кода можно достичь 80% возможной оптимальности, imho
Код оптимизировал настолько, насколько мне позволили мои познания. Интересно, что операции с БД занимают в процентном соотношении немного времени. Из-за количества переменных даже операции в памяти с инсертлистом занимают немало.

Кстати, для меня сюрпризом были, что запрос из while select исполняется по мере выполнения цикла (если верить систем монитору). Собственно селект занимает пару минут, не больше. Возможно, есть способ заставить выполнить весь запрос (т.е. набрать рекордсет), а потом по нему производить операции?

Насчет приемлимости - да, операция нечастая, и в принципе приемлема, но клиент готов платить если улучшение будет раза в два...
Высокоуровневой средой можно пожерствовать, посколку код не универсален, а под одного клиента, ну и в подзабтом SQL поупражняться
__________________
--
regards, Oleksandr