Перейти к содержимому


Фото
- - - - -

SQL запрос. Зависает на выполнении.


  • Чтобы отвечать, сперва войдите на форум
9 ответов в теме

#1 Enhill

Enhill
  • Пользователь
  • 168 сообщений
  • Версия CMS:2.x

Опубликовано 22.01.2019 - 16:06

Добрый вечер. Возникла необходимость удалить все варианты у которых задублировано поле "external_id", кроме последнего.

 

Получился запрос:
 

DELETE n1 FROM s_variants n1, s_variants n2 WHERE n1.id < n2.id AND n1.external_id = n2.external_id

Удаляет задублированное поле с меньшим id

 

На тестовом магазине с маленьким количеством товара все ок. На магазине в 10000 товаров захлебывается. Помогите пожалуйста упростить запрос. Может есть альтернатива?



#2 yr4ik

yr4ik
  • Фрилансер
  • 916 сообщений
  • Дизайн, Программирование, Верстка
  • Версия CMS:1.x, 2.x
  • Откуда:Украина Чернигов

Опубликовано 22.01.2019 - 16:34

может так. Не проверял

DELETE n1 FROM s_variants n1 INNER JOIN s_variants n2 ON (n1.external_id = n2.external_id) WHERE n1.id < n2.id 


#3 Sheeft

Sheeft
  • Администратор
  • 1 652 сообщений
  • Пользователь
  • Откуда:Москва

Опубликовано 22.01.2019 - 17:07

более извращенный вариант если предыдущие не сработали - сделать экспорт таблицы, указать уникальным экстернал айди в структуре, сделать импорт, убрать уникальность - гарантировано сработает :)



#4 phukortsin

phukortsin
  • Фрилансер
  • 729 сообщений
  • Программирование, Пользователь
  • Версия CMS:2.x
  • Откуда:Львов

Опубликовано 22.01.2019 - 17:59

Попробуйте к своему запросу добавить что-то типа  Limit 100.

И запускать несколько раз.



#5 Enhill

Enhill
  • Пользователь
  • 168 сообщений
  • Версия CMS:2.x

Опубликовано 22.01.2019 - 23:20

Как доберусь до компьютера обязательно попробую все предложенные варианты.

 

более извращенный вариант если предыдущие не сработали - сделать экспорт таблицы, указать уникальным экстернал айди в структуре, сделать импорт, убрать уникальность - гарантировано сработает :)

тут загвоздка в том, что external_id это уникальный код из 1с, который присваивается вариантам при первой выгрузке. А еще у нас работает группировка товаров по другому id. Иногда наш закупщик путается и заводит в 1с неправильный id группы. После исправления ошибки, если товар успел выгрузиться на сайт с неправильным id группы, создается дублирующий вариант с тем же уникальным кодом external_id, по которому происходит обновление цен и наличия. Получается что созданный до этого первый вариант перестает обновлять наличие и цену и вообще может висеть не в своем товаре (в следствие ошибки заведения в 1с). Этот запрос и был призван такое исправлять. то есть при каждой выгрузке проверять задвоенные варианты и оставлять только последний из созданных.

Была мысль запихнуть его прямо в обработчик выгрузки из 1с, но теперь понимаю, что решение очень нерациональное. Может подскажете куда копнуть?



#6 Sheeft

Sheeft
  • Администратор
  • 1 652 сообщений
  • Пользователь
  • Откуда:Москва

Опубликовано 22.01.2019 - 23:39

дык я же говорю сделайте уникальным экстернал айди, тем самым вы не сможете добавить товар с дублирующим экс айди. я с таким развлекался когда делал парсер мультипоставщика, только там добавлял еще поле поставщика, но если у вас товар только из 1с и весь с внешним ключем (экс айди) тогда это решение для вас.



#7 Enhill

Enhill
  • Пользователь
  • 168 сообщений
  • Версия CMS:2.x

Опубликовано 22.01.2019 - 23:58

дык я же говорю сделайте уникальным экстернал айди, тем самым вы не сможете добавить товар с дублирующим экс айди. я с таким развлекался когда делал парсер мультипоставщика, только там добавлял еще поле поставщика, но если у вас товар только из 1с и весь с внешним ключем (экс айди) тогда это решение для вас.

Вы говорите о индексе UNIQUE? Если сделать это поле уникальным, тогда после исправления ошибки в 1с, не будет создан правильный вариант, так как на сайте висит старый, с неправильным ид группы, но с таким же эксернал ид.

 

Ошибки в 1с находим не сразу, к этому времени уже создаются варианты с неправильными данными. Часто бывает так, что вариант создается не в своем товаре и вычислить его потом очень трудно. В итоге второй созданный вариант является правильным, так как создается уже после исправления в 1с. Я вижу вариант с удалением, если найден дубль экстернал ид.  АмМожет я вас неправильно понял...



#8 Sheeft

Sheeft
  • Администратор
  • 1 652 сообщений
  • Пользователь
  • Откуда:Москва

Опубликовано 23.01.2019 - 00:05

правильно поняли. просто так если один раз вычистить все больше таких косяков быть не должно. ну если так то проще при добавлении тогда проверять. у вас загрузка из 1с идет через файл обмена или напрямую в базу? встречал оба варианта реализации. Вообще пишите в личку\скайп\телегу - помогу разобраться.



#9 Enhill

Enhill
  • Пользователь
  • 168 сообщений
  • Версия CMS:2.x

Опубликовано 23.01.2019 - 00:12

Через файл обмена. Обязательно завтра напишу, спасибо за помощь. Попробую сначала уменьшить выборку, ведь такая проблема существует только с группированными товарами у которых есть гроуп ид.



#10 phukortsin

phukortsin
  • Фрилансер
  • 729 сообщений
  • Программирование, Пользователь
  • Версия CMS:2.x
  • Откуда:Львов

Опубликовано 23.01.2019 - 09:57

Как доберусь до компьютера обязательно попробую все предложенные варианты.
 
тут загвоздка в том, что external_id это уникальный код из 1с, который присваивается вариантам при первой выгрузке. А еще у нас работает группировка товаров по другому id. Иногда наш закупщик путается и заводит в 1с неправильный id группы. После исправления ошибки, если товар успел выгрузиться на сайт с неправильным id группы, создается дублирующий вариант с тем же уникальным кодом external_id, по которому происходит обновление цен и наличия. Получается что созданный до этого первый вариант перестает обновлять наличие и цену и вообще может висеть не в своем товаре (в следствие ошибки заведения в 1с). Этот запрос и был призван такое исправлять. то есть при каждой выгрузке проверять задвоенные варианты и оставлять только последний из созданных.
Была мысль запихнуть его прямо в обработчик выгрузки из 1с, но теперь понимаю, что решение очень нерациональное. Может подскажете куда копнуть?

 

Решение станет вполне нормальным и рацональным, если Вы этот запрос будет делать не глобальным, как сейчас, а применительно к конкретного текущему обрабатываемому значению.






0 пользователей читают эту тему

0 пользователей, 0 гостей, 0 скрытых