Форум MySQL

Есть список имен в Mysql, например:

id 0, Вася id 1, Петя id 2, Женя id 3, Катя id 4, Саша

Мне нужно вывести их в таблице, ну это не суть, в таблице дать возможность поднять Катю наверх или спустить вниз, таким образом что бы id тоже изменился, например:

//Вверх катю id 0, Вася id 1, Петя id 2, Катя id 3, Женя id 4, Саша

Вы заметили у Кати ID уже не 3 а 2.

//Вниз Васю id 0, Петя id 1, Вася id 2, Катя id 3, Женя id 4, Саша

И тут у Васи ID не 0 а 1.

Т.е. тот кто был на ID выше что бы ушел вниз а тот кто был на ID ниже что бы ушел вверх. По ID!

Как такое реализовать? Помогите пожалуйста всю голову сломал об стену )

Это можно сделать одним запросом.
Что-то подобное я уже делал. Вспомню только...

если id - первичный ключ, то Вы зря навесили на него задачу сортировки. Введите еще одно поле.

Если ввести новое поле, то резонно будет сделать его уникальным. Тут-то встаёт та же самая задача инкремента/декремента значения уникального поля. А это самое интересное...

Это как раз делается просто. UPDATE tbl SET pos = $pos1+$pos2 -pos WHERE pos IN ($pos1, $pos2)
А зачем делать его уникальным?

[i]>Это как раз делается просто. UPDATE tbl SET pos = $pos1+$pos2 -pos WHERE pos IN ($pos1, $pos2)[/i]
И получим ошибку типа "duplicate unique key".

>А зачем делать его уникальным?
Чтобы на уровне СУБД исключить потенциальные ошибки в коде по сортировке
Ну а если уникальным не делать, то действительно всё просто...

UPDATE tbl SET pos = pos -  ($pos1 + $pos2 ) WHERE pos  IN ( $pos1, $pos2);  UPDATE tbl SET pos = -pos WHERE pos  IN ( -$pos1, -$pos2);

Да, но только pos в таких случаях не только уникален, но ещё и неотрицателен.
А неортицательность необходима по той же причине, что и уникальность.

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

ни тот ни другой фактор сортировать таблицу не мешают.
Тем не менее, вариант реализации задачи при наличии обоих факторов пока не представлен...
А заключение в транзакцию не решит вопрос с неотрицательностью.

1. чем обусловлено требование неотрицательного номера позиции?

2. чем обусловлено требование уникального индекса на поле номера позиции?

1. чем обусловлено требование неотрицательного номера позиции?
Исходя из предметной области задачи номер позиции не может быть отрицательным
2. чем обусловлено требование уникального индекса на поле номера позиции?
Исходя из предметной области задачи номера позиций не могут совпадать

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

Вопрос закрыт.

>А еще он не может быть нулевым, нецелочисленным, неопределеленным
Конечно. Мы ведь фактически имеем дело с порядковым номером.

>не может выходить за множество номеров имеющихся строк.
И тем самым исключить возможность добавления новых элементов в таблицу ?

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

>>не может выходить за множество номеров имеющихся строк.
>И тем самым исключить возможность добавления новых элементов в таблицу ?

почему же? Добавление новой строки как раз расширяет область определения позиции на один элемент. Здесь всё в порядке.



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

Проверку уникальности можно вообще не вводить. Поле неключевое.
Вы уж выберите что-нибудь одно.

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

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

>Вы уж выберите что-нибудь одно.[/i]
Выбираю неключевое, но уникальное и неотрицательное поле.