Ответы (61)
-
Антон, SELECT DISTINCT в другую табличку, снести всё из исходной, а потом вернуть — разве не покатит?
-
покатит. но требует другую табличку. а мы решаем хитрые ж пути :)
-
первичный ключ есть. и есть поле с дублирующимися значениями. нужно оставить только первый из дубликатов, удалив остальные. вот точная формулировка задачи.
-
делаем селект с группировкой по всем дублирующимся полям, далее по primary key берем max(id) или min(id). В результате получаем список id которые не надо удалять. Далее в delete вызываем where id not in (наш запрос)
-
Спасибо большое, сделал вот так как ты сказал. Супер. =)
-
дубликаты совсем одинаковые или все же первичный ключ есть?
-
а если таблица внезапно на миллиард записей? :)
-
Тогда список id-шников внезапно не влезет в максимальный размер запроса.
-
Планировщик как бе обычно умнее и переколбашивает как надо запрос, так что такого прикола не будет.
-
И кстати, даже если и влезет, устанешь ждать когда в этом случае конструкция where id not in (наш запрос) отработает.
-
Имхо в любом случае простая выборка, DELETE FROM и вставка быстрее будут.
-
Мы там пользуемся MS SQL, Oracle 9i, MySQL и PosgreSQL тоже иногда бывает.
-
как бе вообще планировщик такое переколбашивает сам, прежде чем выполнять иначе если все делать в лоб будет трындец производительности.
-
в этом случае прийдется сильно зубодробительный DELETE писать. А так вполне себе работает и переколбашивается.
-
В варианте со временной табличкой ничего не зубодробительный. DELETE FROM sometable. Экстремально зубодробительно, да.
-
я не про таблицу временную а про развертывание select в delete. Да такое можно сделать, но лучше не думать про это. Временная же табличка в случае если надо удалить мало overhead.
-
Что такое "мало overhead"? Как-то не слишком по-русски. Смысл предложения я не понял вообще.
-
тфу. Дольше отрабатывать будет и сильнее диск насиловать. Вообщем прежде чем что-то делать я бы оценил количество дубликатов и возможно добавил бы еще одну связку в select чтобы получить то что надо удалить. Т.е. чтоб операция была просто in. Если дубликатов мало, то такая операция пройдет быстрее. Если их столько сколько обычных записей, то можно и через табличку. Скорость получим ту же.
-
Я машинально подумал, что дубликатов больше. Раз эдак в несколько. Шаблон мышления.
-
Там 50 записей, из них примерно у каждого третьего есть 1 дубликат.
-
вот на таких случаях городить табличку дополнительную не надо точно.
-
Всего??? :))) Тогда вообще не принципиально же! ;)))) А мы тут миллиарды записей обсуждаем.
-
В твоем кокретном случае даже руками было бы недолго.
-
Ага. "Лучше день потерять, потом за пять минут долететь" © Орел из "Крылья, ноги, хвосты" ;)
-
Ну просто когда в следующий раз у меня возникнет такая проблема — я за 5 минут ее "долечу", неважно на каких масштабах )
-
Почему я в нем могу разочароваться? ) в этой таблице в принципе не будет больше 1000 записей..
-
Неважно, 50 или 1000. А так да, для миллионных таблиц этот способ будет медленным.
-
1000 для БД — это тот же масштаб. Зовётся по-русски "хрен да маленько".
-
Вы не планируете больше ни с какой таблицев по жизни общаться?
-
Планирую. Но этот способ именно для моего частного конкретного случая — идеален )
-
Ну просто если планируете, то последуйте совету: планировщик — это не человек и даже не машина, чтобы не разочароваться очень сильно не стоит на него возлагать много надежд.
-
Кстати, я вспомнил, откуда у меня эта идея про временную табличку. Мы так реально большую таблицу на боевом сервере от дубелей чистили. Выборка, очистка, залили обратно. Очень быстро получились второй и третий шаги.
-
2 с хреном миллиарда записей на боевом сервере. Тот же способ, время простоя минимальное.
-
по вашей теории оно должно на наворачиваться на 10 тысячах :]
-
datacompboy: основное для max()/min() выборок с группировками индексы, без них всё ляжет, это факт
