Эффективность работы при обновлении и настройке прайсов
Добавлено: 29 июн 2016 16:46
Нужны Ваши советы.
Хотелось бы улучшать скорость обработки прайсов путем оптимизации настроек, однако при большом СТУС (около 50тыс. товаров) и большом количестве прайсов (около 300) оптимизацию в основной базе в ПЛИ проводить сложно из-за длительного обновления каждого прайса при текущих размерах баз СТУС и СТИПП. Хорошо было бы иметь журнал обновления каждого прайса в виде автоформируемого отчета, чтобы потом можно было анализировать информацию и делать какие-то выводы. Следить каждый раз при обновлении прайса за журналом довольно сложно.
Можно конечно оптимизировать прайсы в отдельной чистой базе с минимально необходимым СТУС и небольшим количеством активных прайсов, чтобы оптимизацию проводить быстро. Однако тут возникает существенное неудобство с переносом настроек прайсов из тестовой базы в основную, поскольку это насколько я знаю можно сделать только вручную.
Также можно конечно узнать время обновления каждого прайса через сводный отчет, который формируется при обновлении нескольких прайсов, однако при окончании обновления нужно ещё успеть нажать кнопку просмотра отчета, поскольку он автоматически не формируется. Кроме того исследования опять же приходится проводить в тестовой базе, поскольку обновление нескольких прайсов (5-7шт.) приводит к переоценке по всем 300 прайсам. Если не удалить весь СТИПП, то переоценка происходит в несколько раз дольше чем обновление этих 5-7 прайсов по отдельности. Если удалить СТИПП, то на переоценку каждого из 300 прайсов тратится 1 секунда. Поэтому и приходится с этими тестами также работать в отдельной тестовой базе. Опять же возникает проблема переноса обновленных настроек прайсов с тестовой базы в основную, что приходится делать вручную.
В итоге получается, что для малых баз СТУС и малого количества прайсов в СТИПП, работа ведется быстро. А если у клиента много товаров в СТУС и много прайсов не получается быстро вносить изменения в настройки и проводить проверки в основной базы да и вся база работает очень медленно: например такая простая операция, как вход в настройки прайса также занимает несколько секунд, а не происходит моментально.
Хотелось бы улучшать скорость обработки прайсов путем оптимизации настроек, однако при большом СТУС (около 50тыс. товаров) и большом количестве прайсов (около 300) оптимизацию в основной базе в ПЛИ проводить сложно из-за длительного обновления каждого прайса при текущих размерах баз СТУС и СТИПП. Хорошо было бы иметь журнал обновления каждого прайса в виде автоформируемого отчета, чтобы потом можно было анализировать информацию и делать какие-то выводы. Следить каждый раз при обновлении прайса за журналом довольно сложно.
Можно конечно оптимизировать прайсы в отдельной чистой базе с минимально необходимым СТУС и небольшим количеством активных прайсов, чтобы оптимизацию проводить быстро. Однако тут возникает существенное неудобство с переносом настроек прайсов из тестовой базы в основную, поскольку это насколько я знаю можно сделать только вручную.
Также можно конечно узнать время обновления каждого прайса через сводный отчет, который формируется при обновлении нескольких прайсов, однако при окончании обновления нужно ещё успеть нажать кнопку просмотра отчета, поскольку он автоматически не формируется. Кроме того исследования опять же приходится проводить в тестовой базе, поскольку обновление нескольких прайсов (5-7шт.) приводит к переоценке по всем 300 прайсам. Если не удалить весь СТИПП, то переоценка происходит в несколько раз дольше чем обновление этих 5-7 прайсов по отдельности. Если удалить СТИПП, то на переоценку каждого из 300 прайсов тратится 1 секунда. Поэтому и приходится с этими тестами также работать в отдельной тестовой базе. Опять же возникает проблема переноса обновленных настроек прайсов с тестовой базы в основную, что приходится делать вручную.
В итоге получается, что для малых баз СТУС и малого количества прайсов в СТИПП, работа ведется быстро. А если у клиента много товаров в СТУС и много прайсов не получается быстро вносить изменения в настройки и проводить проверки в основной базы да и вся база работает очень медленно: например такая простая операция, как вход в настройки прайса также занимает несколько секунд, а не происходит моментально.