Андрей ПанфиловПылинкаА зачем тогда вообще проверять знание SQL? Его аналогично можно "изучить". Аналогично можно "за неделю изучить" множество разных вещей.Как это для чего? чтобы начать общаться, например, в этом топике никто так и не смог привести правильный ответ: все приведенные запросы могут как удалить "не дубликаты", так и не удалить дубликаты, просто потому, что в базу доступ обычно конкурентный.

а какой правильный запрос может гарантированно удалить все дубликаты, которые появятся после? Я чего то не понял.
Если вы про уровень изоляции транзакции типа READ COMMITED, то это режим по умолчанию для баз, а AutoCommit нынче стоит по умочланию в большинстве реализаций jdbc драйверов.

Андрей ПанфиловОзверина какой правильный запрос может гарантированно удалить все дубликаты, которые появятся после? Я чего то не понял.Ну а "после" тут причем? вот вы в delete завязались на то, что удаляете все что не min/max, какие гарантии что в соседней сессии кто-то этот самый min/max не удалит?

там, где having count(id)>1 - таким.

Андрей ПанфиловОзверинтам, где having count(id)>1 - таким.это как? вот вы запустили свой убер-delete, в соседней сессии ваш min/max удалили, ваша транзакция этот min/max все еще видит, что получаем на выходе? удаленный "недубликат".

похожее поведение будет и без аналитических функций, если кто-то не удалит, а вставит данные. А если кто то параллельно удалить ваши данные, а кто-то еще параллельно вставит их - так поведение и вовсе будет полностью аналогичным. Тут можно придумать что угодно, но это не решается на уровне запроса - это решается на уровне логики приложения или конкретной СУБД.

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