Какое СУБД Вы используете? Для большинства СУБД нет понятия "середина/начало/конец таблицы" (таблица - множество записей). Т.е. при вставке записи никто/ничто не будет "шерстить половину записей" (структура индексов - древовидная, глубина примерно одинакова для всех записей).
Осмысленным может быть, например, "середина/начало/конец выборки с таким-то ORDER BY..."

mephПервое что приходит в голову это ORDER BY prior, где prior уникальное.
Или проблема в другом? в том, что при одинаковых значениях prior теряется однозначность?

Навскидку, пошел бы путем разрешения коллизии одинаковых значений prior - добавил бы еще одно поле (с автоматически генерируемым значением при вставке а возможно и обновлении - identity или timestamp или просто дата-время или другое но такое, чтобы пара значений prior + еще_одно_поле было уникальным), которое бы и использовал в
ORDER BY prior, еще_одно_поле asc|desc

Old NickА теперь добавим строку между 2 и 3, какое значение указать? 2 или 3 или 2,5?
вариант 2,5
www.dkoh.netU etogo podhoda ets' ochevidnye ogranichenija, no on prost v realizacii.
его можно слегка переиначить(технически) - сделать поле prior строковым типом, и тогда между "2" и "3" указывать "29", между "2" и "29" - "28", а между "29" и "3" - "299" и т.д., т.е. к "строке сверху" добавляем символ - максимальный из возможных в данном месте для сортировки. Сортировка по строковому типу даст нужный порядок.
В таком случае ограничение останется только на размер строкового поля. Ряд символов конечно же целесообразно расширить.

mephВсе же 50 000 апдейтов делать не очень хочется. Хотелось бы сделать, так чтобы потом система не легла в один прекрасный момент.
Ну так чем не подходят предложенные варианты?
1) дополнительное поле (в этом случае не вижу ограничений)
2) prior - строкового/символьного типа,
правда здесь я перемудрил
автормежду "2" и "3" указывать "29", между "2" и "29" - "28", а между "29" и "3" - "299" и т.д.
конечно же, выбирать следует символ со "средним для сортировки" значением между предыдущим и последующим элементом, т.е. между "2" и "3" указывать "25", между "2" и "25" - "23"(или "22"), ну и между "29" и "3" - "295" и т.д.
Диапазон символов расширить, т.е. помимо "1-9" использовать другие, тогда на одну символьную позицию "втиснется" несколько сотен элементов...

meph LR
Ну так чем не подходят предложенные варианты?
1) дополнительное поле (в этом случае не вижу ограничений)

Вот с этого места поподробнее пожалуйста.
А насчет символьного поля у меня есть сомнения...насчет оптимальности и удобства использования такого подохода.
Расскажите о том, как Вы предлогаете использовать допольнительное поле.
Для решения такой задачи на 100 тыс.
mephОсталось только придумаьт такой механизм, который был бы применим для ВСЕХ товаров, а не для пары-тройки самых важных. Например, чтобы была возможность сегодня выводить колбасу за сыром, но перед рыбой, а завтра все в обратном порядке.
дополнительное поле наверное не поможет, разве что долнительное поле prior для категории/группы/вида наименований, т.е.

ORDER BY категория.prior, наименование.prior

А мне почему-то (от рыбы, колбасы и сыра:) померещилась другая задача - "временно акцентировать" какой-то товар, "пристегнуть" его вверх списка (акции там разные, распродажи)
prior - постоянный, штатный приоритет
prior_tmp - временный (для акцентирования товара)

ORDER BY <если prior_tmp!=null тогда 0 иначе prior>, prior_tmp

- одновременно акцентированного товара не может быть много, значения prior_tmp могут задаваться "вручную" пользователем, в случае автоматизации "шерстить" придется немного, где prior_tmp!=null

- предусмотреть действие "удаления всех акцентуаций"

- если есть необходимость, предусмотреть действие "перевода временного приоритета в постоянный" - тяжелое, но осознанное действие для всего множества, в результате "временный" порядок становится "постоянным" (а prior_tmp для всех элементов =null)

iscrafmПредложил само ранжирование, а ранжируют все что попадается под руку. Даже в ночных клубах фейс-контроль работает по принципу Парето. 20% запущенных в клуб девушек с хорошей внешностью привлекают выручку 80% клиентов.
:) а если запускать 50% девушек с хорошей внешностью? клиенты разорятся?
Никак для себя не уясню - это (попытки применения принципа Паретто, ABC-анализ) "дань моде" или уже "норма жизни" современных ИС?

Кстати, в одной статье, посвященной техноценозу (http://www.kudrinbi.ru/ когда-то кто-то здесь давал ссылку), русский профессор Кудрин опубликовал несколько другое соотношение, не такое "универсальное" как у Паретто, но, как я понял, основанное на хорошей статистике:
5-10% особей-изделий относится к "ноевым" кастам (уникальным, редким), что составляет 40-60% видового состава - объема словаря
ну и
40-60% всех особей-изделий попадают в "саранчевые" касты (массовые), что составляет 5-10% общего числа видов

Это я к тому, что, возможно, специальные исследования "фейс-контроля в ночных клубах" дадут совершенное другой результат(выручка зависит от других факторов) или другое соотношение (не 20-80, и в каждом клубе - свое), imho естественно :)

УриЕсли использовать другие символы (возьмем один байт, 255 символов) - то удастся вставить 7 элементов и потом - новый разряд.
Да, действительно, фигово получается...

Пока что единственным очевидно "правильным" решением для большого количества элементов выглядит наличие классификатора c приоритетом групп/подгрупп и относительно небольшим количеством элементов в подгруппе.
Возможно ли сделать подобный "классификатор" для упорядочивания, который бы поддерживался системой автоматически, без вмешательства пользователя, и был бы "дешевле перенумерования хвоста списка"? Т.е. некая дополнительная саморегулируемая иерархическая структура... х.з., тут, наверное, придется экспериментировать (макс.колич. элементов в группе, постоянное или зависит от общего количества (процент), и т.п.)