22.11.2008 13:00 | |
rollarrПользователь iNETsHOP Количество сообщений 14 Зарегистрирован: 13-10-2007, 02:44:29 |
Импорт прайс-листов в iNETsHOP
Иногда сохранение прайса в базу идёт медленно. Я имею ввиду третью стадию, которая идёт после сравнения прайс-листа поставщика с уже существующими позициями в базе. Как этот процесс можно ускорить? И можно ли ускорить вообще... |
22.11.2008 17:39 | |
supportSupport Количество сообщений 1199 Зарегистрирован: 11-04-2008, 19:11:57 |
Ускорение импорта прайс-листов
Увеличение времени записи (обновления) прайса непосредственно в базу данных может быть из-за большого проценка обновляемых позиций (цена, описание, примечание и.т.п.), т.к. все изменяемые поля логируются, т.е. по ним ведётся история. Но есть и приятная новость: SQL-запросы сохранения прайса уже переделаны на динамические и несколько дней тестируются в боевом режиме у нескольких клиентов. С выходом обновлений версии БД 0033 неудобства должны исчезнуть и нагрузка на сервер (компьютер пользователя на котором стоит БД или выделенный сервр) - уменьшится. |
14.06.2011 21:00 | |
bombПосетитель Количество сообщений 3 Зарегистрирован: 14-06-2011, 17:42:03 |
Отключите триггеры логирования. Именно они и тормозят базу на последнем этапе. Таблица SUPPIERS_GOODS Три тригеера начинающихся с LOG_. Для разработчиков: Мне вот интересно, зачем делать ***графию из серии сборка SQL запроса внутри SQL сервера? Неужели так сложно собрать запрос на клиенте? Да и иной раз встречаются шедевры, навроде, сначала CAST к фиксированной длинне, а уж потом TRIM - это чтоб уж наверняка? Или каскад переприсваиваний? Или TRIM обязательно делать на стороне SQL? Или почти каждый запрос пускать через exec_sql, вместо прямого вызова? В том же импорте для сравнения можно выбирать не по одной записи, а группой - быстрее будет. |
14.06.2011 21:37 | |
supportSupport Количество сообщений 1199 Зарегистрирован: 11-04-2008, 19:11:57 |
Триггеры логирования
Триггеры логирования отключить невозможно. По поводу TRIM и CAST вкратце - TRIM не проходит на TEXT, только на VARCHAR и подобных. По поводу exec_sql - да, выходит так надо, так работают многие в том числе и мы. Импорт учитывает много ньюансов, с которыми вы видимо ещё не сталкивались, поэтому он работает именно так. Если у вас есть конструктивные предложения - мы их рассмотрим. |
14.06.2011 23:21 | |
bombПосетитель Количество сообщений 3 Зарегистрирован: 14-06-2011, 17:42:03 |
Отлично. Триггеры я отключил. Скорость импорта возросла на последнем этапе. Мне было бы интересно узнать, какие такие особые причины мешают собирать запрос на стороне клиента? Или что мешает сделать SELECT по WHERE IN, а не дергать базу по одной строчке? Накладные расходы на один запрос никто не отменял. Также интересно как сказываются на производительности конструкции из 5 вложенных подряд подзапросов. И какие-такие причины вынудили использовать такую жуткую семантику. Также интересно, почему в SQL море комментариев, явно не ускоряющих скорость передачи запроса на сервер. |
14.06.2011 23:25 | |
bombПосетитель Количество сообщений 3 Зарегистрирован: 14-06-2011, 17:42:03 |
SQL в любом случае не быстрый язык. А делфи, пускай и 5-ый - намного быстрее его. |