вот, ещё вариант :)
в данном случае ограничение в 10 вставок ( хотя кол-во нулей можно добавить ), но мой вариант я считаю получше, в нем минимум 64000 вставок до перестройки ключей, хотя ключ может разростись что тоже потребует перестройки

а, все я понял ваш хитрый план. Но мне почему-то тоже кажется что это какой-то костыль и наверно где-то что-то надо было сделать по-другому :)

А конкретено - не понятен принцип сортировки, например если бы была еще цена, то сортировать для вывода на экран можно было бы по ней. А тут какой-то мифический ключ, по которому и нужно отсортировать. В общем если нет никакого реального параметра по которому можно проводить сортировку для вывода на экран (например цена или дата добавления) то можно ввести виртуальный и сортировать по нему. Например, усовершенствовать вариант, который уже предлагали: добавляем в таблицу еще одно поле, с индексами в нужном отсортированном порядке вещественного типа. Затем когда нам нужно сделать вставку, просто добавляем новую запись, а в качестве сортируемого параметра указываем как уже предлагали (1 + 2) / 2 = 1.5 Разница в том, что мы имеем почти бесконечный запас возможностей для вставки (тк тип записи вещественный и делить на 2 можно досмерти), а так же не пляшем с бубном около id и оставляем его автоинкрементным.

o7412369815963
в данном случае ограничение в 10 вставок

Это типа пессимистический прогноз на входные данные, если пользователь подряд будет вставлять на вторую позицию? Ох он коварный! :)
Ну да, это ведь пример, служащий для задания направление мысли, так сказать. Этот интервал нужно задавать исключительно по фактическим данным ваших Use cases. Можно даже алгоритм выбрать нелинейный - чтобы увеличить кол-во возможных вставок без “ночных” изменений ключей.

Zubchick
Разница в том, что мы имеем почти бесконечный запас возможностей для вставки (тк тип записи вещественный и делить на 2 можно досмерти)

Я привел пример с целыми числами неспроста. И уже не вернулся к предложенному ранее decimal(10, 2).
Операции с вещественными числами все таки более затратны. Если автор поднимает вопрос о производительности, то, наверное, этот параметр важен.

Zubchick
так же не пляшем с бубном около id и оставляем его автоинкрементным

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

Zubchick
а, все я понял ваш хитрый план. Но мне почему-то тоже кажется что это какой-то костыль и наверно где-то что-то надо было сделать по-другому :)
А конкретено - не понятен принцип сортировки, например если бы была еще цена, то сортировать для вывода на экран можно было бы по ней.

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

Lexander
Тут я согласен при определенных исходных условиях (коих мы полностью не знаем).

условия все известны, полностью задачу описал в 3-м посте

o7412369815963
типа того, но если мне ещё раз нужно будет вставить после “('o7412369815963', 10, 1),”, какой все будет браться и откуда будет браться?
чтение не будет затратным т.к. это простой селект: “select name,VES from table order by VES”

Немного с запозданием, но отвечу…

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

o7412369815963
условия все известны, полностью задачу описал в 3-м посте

Перечитал пост.
В общем-то можно спокойно использовать вариант с весом. Только реализовать вакуумирование… :-)

P.S. Одним запросом не решишь.

o7412369815963
условия все известны, полностью задачу описал в 3-м посте

Размер базы?
Способ работы с базой (ХП или прямые инсерты)?
Расположение базы?
…

Еще одна идея использовать linked list, а нумерацию проделаешь после запроса. Например как здесь: http://dotnetthoughts.wordpress.com/2008/01/01/persisting-the-doubly-linked-list/ В принципе неважно как ты это реализуешь, но если будешь хранить не порядковый номер, а ParentId, то вставить или поменять местами не составит труда.

nerijus
Еще одна идея использовать linked list, а нумерацию проделаешь после запроса. Например как здесь: http://dotnetthoughts.wordpress.com/2008/01/01/persisting-the-doubly-linked-list/ В принципе неважно как ты это реализуешь, но если будешь хранить не порядковый номер, а ParentId, то вставить или поменять местами не составит труда.

в данном методе вставить элементы можно только к элементам верхнего уровня, к вставленным объектам не вставить… типа того, имхо, да и выборка не простой селект.

Lexander

o7412369815963
условия все известны, полностью задачу описал в 3-м посте

Размер базы?
Способ работы с базой (ХП или прямые инсерты)?
Расположение базы?
…

база - MongoDB (sql привел для объяснения), сейчас в данной коллекции около 5000 документов, алгоритм хочу с расчетом на будущее (до 1млн), да и вообще полезно знать подобные алгоритмы

размер базы, думаю, в данном случае не важен, буть то он 1Мб или 1Гб. вставка идет одной/двумя командами - алгоритм не измениться. конечно может от размера БД хост будет плющить, тут уже распараллеливать , кластеризовать и т.д, но это уже совсем другая задача…