Чистка существующей таблицы
через
delete from where
создание новой вставка данных и удаление старой
insert into select from where
Есть у нас спецы по MS SQL?

Дроп быстрее. Не всегда возможен

(1) то есть ты утверждаешь 4 операции
create
select
insert
drop
быстрее чем 1 операция
delete
для базы в simple?

Не знаю что за база симпл но при существенном объеме данных которые нужно удалить и незначительном остатке дроп будет быстрее. Проверено.

(3) не знаешь что такое recovery model?
В simple не пишется лог, а значит скорость delete максимально быстрая.

гыгы, ухтинская мразь знатно обосралась ;)
это тебе не насрального пиарить.
вот тебе лучше рубанок новый...

(5) ванюш, я понимаю что ты не часто в жизни слышал про базы данных а [...] хоть что хотелось. А я так то довольно долго в теме.

(7) когда с людьми разговариваешь, [...] изо рта вынь...

Guk [...] изо рта вынь

Курильщик [...] изо рта вынь

на одном уровне общаются гук и курильщик

и только шмондер общается на высшем уровне ;) бугагага...

про низость уровня ничего не было написано, но гукЪ всё сам понимает

шмондер пытается умничать, но все равно он мудак...

Guk мудак

Курильщик мудак

Guk гыгы, ухтинская мразь знатно обосралась ;)
это тебе не насрального пиарить.
вот тебе лучше рубанок новый...

Да он его лет 5 изучать будет

(20) ему нечем изучать. у него вся голова на фюрера-нсрального заточена...

(8) у тебя кроме критического отсутствует и логическое?

Fynjy для базы в simple

Курильщик Не знаю что за база симпл

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

Guk мудак

(25) у меня все гуд. Работы правда очень много и тупой админ настаивает на дропе безосновательно (он так видит).
А в чем агрессия то?

вопрос

Что быстрее на уровне MS SQL
Чистка существующей таблицы
через
delete from where
создание новой вставка данных и удаление старой
insert into select from where
Есть у нас спецы по MS SQL?

ответ.

Курильщик Дроп быстрее. Не всегда возможен

тебя не устроил мой ответ, зачем вся остальная токсичная херня.

одно дело когда адовый дебиловатый мудак guk так себя ведет другое дело ты, нахера тебе это?

Курильщик (22) антон, ты чего такой агрессивный

Fynjy (25)
А в чем агрессия то?

Курильщик (26) да не знаю даже.

[smile=:D]

(27) да не устроил, потому что требует обоснования.
4 операции против 1
Я добавил условий ты сказал глупость нивелировав свой первый ответ тем, что MS SQL ты не знаешь.

(30) тестил, правда давно, но записей были миллионы

У ms sql нет разве чего нибудь типа explain plan? Наверняка ведь что то есть аналогичное

(32) есть "execution plan" но он не даст обоснования. Потому что таблиц несколько сотен. Строить его для каждой команды делать анализ - безумно время затратно.
PS: нужно быть мужиком и завести себе логин на SQL.RU ) там точно есть зубры в этом вопросе.

Курильщик мудак

Fynjy там точно есть зубры в этом вопросе

Есть

думаю, дроп полюбас быстрее, независимо от модели

Fynjy создание новой вставка данных и удаление старой

Зависит от объема вставляемых данных.
Возможно, и через delete быстрее будет.

(0) однозначно delete медленней.

В разы

А truncate?

(0) truncate table и никаких вопросов более

(41) нужно оставить половину записей

(42) Тогда через drop быстрее будет.

(42) Тогда о каких дропах может идти речь? delete where

(44) не просто дроп
create
select
insert
drop

(44) нет

Но если число удаляемых строк большое — особенно когда оно составляет большую долю строк таблицы, удаление с полной записью операции в журнале будет слишком медленным. В этом случае стоит подумать об использовании операции неполного протоколирования, такой как SELECT INTO, для копирования уникальных строк (с номером 1) в другую таблицу. После этого оригинальная таблица удаляется, затем новой таблице присваивается имя удаленной таблицы, воссоздаются ограничения индексы и триггеры.
https://professorweb.ru/my/sql-server/window-functions/level3/3_5.php

SQL не заточен на удаление записей

(47) не качается готовое решение

(46) Не наш случай. В (42) сказано про половину записей. При такой пропорции копировать и переименовывать выйдет накладнее. Не говоря уже о том что работы кодеру гораздо больше.

Скачал готовое решение посмотрю

(51) Интересно было бы попробовать оба способа, как в итоге быстрее получится.

А то у теоретиков мнения разделились.

(52) в выходной буду резать проведу эксперимент для самой большой таблице на 15 гиг

(52) Тут однозначного ответа быть не может. Зависит от пропорции оставшихся/удаляемых записей, наличия и пригодности индексов, модели базы. Как человек ленивый, я предпочитаю использовать delete, там писать руками надо меньше, но желательно уметь по-всякому. Дабы если заказчик потребовал сделать строго по-своему, суметь выполнить задачу.

К ленивости плюс 1 )