Jump to content

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


Recommended Posts

Добрый вечер. Возникла необходимость удалить все варианты у которых задублировано поле "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 товаров захлебывается. Помогите пожалуйста упростить запрос. Может есть альтернатива?

Link to post
Share on other sites

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

Link to post
Share on other sites

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

 

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

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

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

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

 

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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

 

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

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

 

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...