Главная » Статьи » "1С" Предприятие |
Скачивать материалы с сайта, могут только зарегистрированные пользователи.
Для регистрации заполните два поля ниже!
Через минуту Вы получите "Гостевой доступ"
Garry Lider январь 2003
Предлагаемые вашему вниманию мемуары посвящены проблеме замедления работы с формой списка, нагруженной вычисляемыми колонками. В конце эссе автор приводит рецепт, который, по его словам, якобы может снять упомянутое торможение. События, описанные ниже разворачивались на: База данных: 1C v7.70.015 for SQL, Оперативный учёт В качестве характерного примера рассматривается форма списка справочника "Номенклатура". В один прекрасный день на пути видоизменения типовой конфигурации я достиг этапа, когда основной проблемой, отравляющей моё существование в рабочее время, стало жалобное нытьё пользователей по поводу крайне медленного перелистывания формы списка справочника "Номенклатура", в частности – в процессе подбора товаров в расходную накладную и счёт. Как оказалось, торможение было вызвано присутствием в этой самой форме трёх вычисляемых колонок, каждая из которых обращалось к актуальным итогам одного из регистров: остатков товаров на складах, резервов и заказов. К сожалению, непреодолимое желание воспользоваться рекомендацией 1С о замене вычисляемой колонки на текстовое поле, было отвергнуто в категоричной форме: менеджер отдела сбыта должен иметь возможность быстро оценивать ситуацию сразу по нескольким номенклатурным позициям, чтобы в случае нехватки какого-нибудь товара предложить клиенту другой, имеющийся на складе. Иногда торможение носило вопиющий характер, когда пользователь набирал, например, "эмаль" и несколько секунд вынужден был ожидать, когда программа перемотает список товаров на букву "э". Немного подумав, я определился с возможными вариантами выхода из кризиса:
Первый способ был оставлен про запас на случай, если ничего более удачного придумать не удастся. Испытания второго привели к плачевным результатам. Была написана функция, возвращающая средствами ADO остаток товара на складе. После попытки применить эту функцию торможение не только не исчезло, а напротив, усугубилось. Третий вариант, как я и предполагал, оказался самым быстрым. Однако я решил, что испытаю его на живой базе, если только четвёртый способ не принесёт желаемого эффекта. Дело в том, что внесение дополнительных реквизитов в справочник товаров вступало в противоречие с моими представлениями о гармонии окружающего мира. "Неужели", – думал я, – "мне придётся нагружать бедный справочник, к которому ежесекундно обращаются все, кому не лень, информацией, которая и так есть в базе данных?". Я решил не рисковать своим психическим здоровьем и немедленно приступил к исследованию оставшегося, чётвёртого варианта. По этой же причине, чтобы у читателя не возникало чувства неловкости или дискомфорта, сразу скажу, что попаданием в десятку оказался последний способ. По крайней мере, полученный с его помощью результат удовлетворил как меня, так и пользователей. Далее речь пойдёт о методике его внедрения. Но сначала позвольте продемонстрировать небольшую сравнительную табличку, в которой приведено время перелистывания справочника каждым из способов:
Итак, внимание, описание четвёртого способа. Для простоты будем считать, что нам нужно ускорить только одну вычисляемую колонку – остаток товара. А ещё будем считать, что регистр "Остатки товаров" состоит из измерения "Товар" и ресурса "Остаток". В качестве хранилища была выбрана СУБД MySQL. Вот, что мне пришлось сделать:
Резюме: если у вас тормозит справочник с вычисляемыми колонками, почему бы вам не попробовать разогнать его описанным способом? С удовольствием по мере сил отвечу на вопросы и постараюсь адекватно воспринять замечания и критику. Пишите. | |||||||||||||
Просмотров: 1433 | | |
Выразить благодарность - Поделиться с друзьями!
Всего комментариев: 0 | |