_Korn в принципе понял, постараюсь чуть детальнее объяснить почему так делать не стоит.
Алгоритмическая сторона
1. Возьмем готовую таблицу, организованную описанным тобой образом, состоящую к примеру из 100 записей. И тут юзер хочет вставить фотографию например под номером 55. Если ты при этом не используешь "нумерацию", твоему скрипту придется вначале вычислять куда её конкретно вставлять -- т.е. по сути пробегать с 1го элемента, до 55го (ну или с конца - неважно), выполняя для каждого по 1 запросу -- в чем же в итоге оптимизация?? вы при своей вставке выполнили N запросов возвращающих по 1 строчке, а я 1 запрос, изменяющий N строк.
2. Ты можешь предложить вариант: "А я возьму, действительно довалю order к своему динамическому связанному списку, и организую дин. структуру vector". Кстати напомню, что именно vector ускоряет вставку в середину, но никак не обычный list. Но даже используя такую структуру, вам все равно при добавлении нового элемента придется изменять счетчики для всех тех, которые идут после него
Практическая сторона
1. А теперь давай не будем забывать, что у нас тут не массивы с указателями, а всего лишь таблица из БД. И один запрос работающий с сонтей строк отработает на порядок быстрее, чем сто запросов, каждый из которых работает с одной строкой. Только что касается моего запроса, то mysql специально оптимизирован именно для подобных простых запросов, пробегающих разок по всей таблице. А вот поиск 1й записи в таблице с данным индексом, её придется именно искать, т.е. перебирать несколько записей, для каждого такого запроса
2. А теперь тривиальная задача вывода всех фоток, которая происходит намного чаще, чем вставка фотки )) Для того чтобы вывести поочередно фотки, вместо одного "большого" запроса "select from.. order by..." тебе придется опять же выполнять кучу "маленьких" -- по одному для каждого элемента. Еще раз повторюсь "большой" будет выполняться лишь ненамного дольше, чем "маленький".
Вывод: БД предоставляет нам кучу возможностей, надо которыми разработчики парились годами, оптимизируя их, давая возможность конечному программеру просто использовать их не заморачиваясь с придумыванием своих способов хранения и пр., нужно стремиться к простоте
