Привет коллеги, может такая тема уже и поднималась, тогда извиняйте

Структурка







В таблице хранятся новости, при выводе они сортируются по полю sort, необходимо сделать так чтоб админ мог указывать положение новости указывая каждой новости положение от 1-5

Это сообщение отредактировал(а) In0stRAnez - 7.9.2015, 17:39

Нет, непонятно.

поправил

Ну это понятно. А проблема-то в чём? В том, что админ неспособен раскидать цифры от 1 до 5 в 5 записей так, чтобы каждая цифирь присутствовала в списке строго 1 раз?
К тому же проблема-то как бы не SQL-ная. Это проблема интерфейса - подстраховать этого дятла (ещё лучше отобрать у него ручной ввод, но оставить 2 кнопки - поднять текущую запись вверх на 1 позицию и соответственно опустить её вниз на 1 позицию). А когда он всё сделает как надо - вот тогда и сгенерить запрос на изменение данных. А если хочется, чтобы каждое такое смещение приводило к выполнению запроса, устанавливающего текущее положение вещей - твой запрос почти правильный. Только он должен идентифицировать записи по их ID, а менять sort. Типа:
этот запрос меняет местами порядок записей с ID, равными 4 и 5.

А мне ничего не понятно. Вы, наверное, что-то одинаковое курите ))



Это вообще можно понять без связи с космосом? Если админ указывает конкретной записи 1, то почему значение 5 должно опустится на 1, а не конкретная запись?
(Я догадываюсь, что всё дело в том, что id и sort одинакового типа, а в предложении яснее лень было выражаться, где что под чем подразумевается).

Надо объяснять задания с т.з. бизнеса, а не реализации. Т.е. например: "админ хочет некоторую запись выводить первой, а у остальных порядок вывода не должен измениться". Такое задание?

И в вашем SQL есть что-то вроде ROW_NUMBER? А то я больше по SQL-SERVER

Этот ответ добавлен с нового Винграда - http://vingrad.com

если просто новость поновее должна идти первой, то вообще не надо ничего делать, никаких апдейтов. Вставку в колонку сортировки делайте с инкрементом, т.е. чтобы значение увеличивалось.
А при выборке меняете условие сортировки на DESC. И профит. Не надо апдейтить каждое поле, не надо ничего смещать. Если только порядок специально админ не захочет менять

Этот ответ добавлен с нового Винграда - http://vingrad.com

Нет, нельзя. Но можно предположить. Особенно когда есть опыт по "разворачиванию" во вменяемый текст такого рода вопросов и приблизительное понимание, что обычно хотят сделать на такой структуре.
Механика же происходящего мне до сих пор непонятна.

НУ собсно тот же случай. Ну вот как "у остальных порядок вывода не должен измениться", если он заведомо изменится у записи, которая была первой?

если я правильно понял и надо просто одну запись подвинуть вперед на первое место, а остальные "сместить", то смещение производится элементарно, арифметикой.

напишу на T-SQL, потому как не знаю, как у вас переменные заводятся:



но вообще что-то наводит на мысль, что сама идея так делать довольно глупая. Нужно просто развернуть сортировку и ничего никогда не смещать. Не должна быть таблица топ новостей ограничена 5-ю записями. По правилам моделирования такой таблицы вообще быть не должно, т.к это не сущность. Просто надо колонку сортировки добавить в таблицу новостей, с инкрементом. А выборку делать с DESC и если надо 5 записей, то ограничить выборку

Этот ответ добавлен с нового Винграда - http://vingrad.com

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


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

как сомнительный? В каких вселенных к обновляемой таблице нет доступа на чтение?

Запрос происходит в одной транзакции, никаких даже с уникальным констрейнтом ошибок не происходит.


если не нравится простой запрос, то можно по классике с джойнами написать:


Этот ответ добавлен с нового Винграда - http://vingrad.com

Пальцы-то сожми...

Уточняю задачу, есть новости, админ хочет сам выставлять порядок отображения новостей в топе, но так как текучка новостей большая и выставлять он будет не так часто, необходимо сделать так чтоб когда админ указывал новой новости конкретную позицию (например позиция 4) то 5 позиция должна остаться неизменной, а 3 -ей станет новость которая была 4, и так далее соответственно!

Коллеги спасибо, за дисскусию

ого. А второй запрос работает?

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

Сначала находите и запоминаете в переменную текущий sort, который надо переставить. А потом апдейт.
Если субд не поддерживает нормальных транзакций, да еще и разрешает делать unique key, то тут уже на свой риск придется писать запросы, вы никак не сможете "перестановку" сделать безопасно.
Ну например. Разбиваем запрос на два, чтобы разрулить то, что субд не умеет обращаться при апдейте к этой же таблице (я с MySQL не знаком):



Теперь всё, что возможно, мы сделали. Никаких обращений к таблице. Единственная, но очень печальная вещь: при одновременном выполнении нескольких запросов начнут случаться казусы. (возможно практически на это можно не обращать внимания, потому что админ скорее всего один и такого не будет).

Если же даже в течении работы одного запроса уникальность проверяется по ходу обновления таблицы, то еще печальнее. Вообще почти ничего сделать толкового нельзя, принципиально. Например, запрос можно рабить уже на 4:



Но тут та же проблема: если кто-то одновременно попытается сделать то же самое, то может попытаться выставить в 0 то, когда 0 временно занят.

И ваш запрос:



так же свалится. В какой-то момент в таблице будет два одинаковых значения.

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

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

Этот ответ добавлен с нового Винграда - http://vingrad.com

и кстати, вы по сути джойн и написали в своем запросе. Хотя это и не легальный для T-SQL синтаксис.

так что в MySQL аналогичный моему запрос будет таким (если ваш работает, то и этот должен):





Этот ответ добавлен с нового Винграда - http://vingrad.com

Да, после рихтовки снитаксиса.

Нет. Ни в один из моментов дублирования нет - каждая атомарка меняет местами два значения.