Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]_Korn в принципе понял, постараюсь чуть детальнее объяснить почему так делать не стоит.
_Korn'у я ответил. Либо я не понял, что он имел ввиду, либо то, что он имел ввиду - чушь, либо он сам не понял, что он имел ввиду Надеюсь, что неправ я

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]1. Возьмем готовую таблицу, организованную описанным тобой образом, состоящую к примеру из 100 записей. И тут юзер хочет вставить фотографию например под номером 55. Если ты при этом не используешь "нумерацию", твоему скрипту придется вначале вычислять куда её конкретно вставлять -- т.е. по сути пробегать с 1го элемента, до 55го (ну или с конца - неважно), выполняя для каждого по 1 запросу -- в чем же в итоге оптимизация?? вы при своей вставке выполнили N запросов возвращающих по 1 строчке, а я 1 запрос, изменяющий N строк.
Вставлять надо не после, например, "двенадцатого", а после записи с конкретным id. В передать эти id в интерфейс не сложно, не так ли? Тогда нужно четыре запроса изменяюшие две, и добавляющие одну строку, как я и написал.

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]2. Ты можешь предложить вариант: "А я возьму, действительно довалю order к своему динамическому связанному списку, и организую дин. структуру vector". Кстати напомню, что именно vector ускоряет вставку в середину, но никак не обычный list. Но даже используя такую структуру, вам все равно при добавлении нового элемента придется изменять счетчики для всех тех, которые идут после него
Нет, я не буду это предлагать По указанной причине.
Вектор ускоряет поиск, а не вставку.

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]1. А теперь давай не будем забывать, что у нас тут не массивы с указателями, а всего лишь таблица из БД. И один запрос работающий с сонтей строк отработает на порядок быстрее, чем сто запросов, каждый из которых работает с одной строкой. Только что касается моего запроса, то mysql специально оптимизирован именно для подобных простых запросов, пробегающих разок по всей таблице. А вот поиск 1й записи в таблице с данным индексом, её придется именно искать, т.е. перебирать несколько записей, для каждого такого запроса
Для того, чтобы ничего не перебирать в бд существуют индексы. Кстати в MySQL для первичных ключей они создаются автоматически. Так что поиск записи по первичному ключу - операция очень быстрая (вектор, ага )
Возможно MySQL действительно оптимизирован под такие запросы. Этого не знал. Где об этом можно прочесть подробнее?
Впрочем если не хочется растить трафик между web и mysql серверами, то можно оформить функции работы со списком в виде хранимых процедур. MySQL 5 это уже умеет.

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]2. А теперь тривиальная задача вывода всех фоток, которая происходит намного чаще, чем вставка фотки )) Для того чтобы вывести поочередно фотки, вместо одного "большого" запроса "select from.. order by..." тебе придется опять же выполнять кучу "маленьких" -- по одному для каждого элемента.* Еще раз повторюсь "большой" будет выполняться лишь ненамного дольше, чем "маленький".
Вот это суровый аргумент Думаю здесь тоже стоит сделать хранимую процедуру... Хочу проверить. Давай проверим? Сделаем галереи На MySQL > 5 и php5 (ну можно и на 4). Есть время?

Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]Вывод: БД предоставляет нам кучу возможностей, надо которыми разработчики парились годами, оптимизируя их, давая возможность конечному программеру просто использовать их не заморачиваясь с придумыванием своих способов хранения и пр., нужно стремиться к простоте
Нужно стремиться к эффективности. Написать 4 строки вместо одной не так уж сложно.

зы: Я тут столкнулся с такой вот программой, где порядок указывается вручную циферкой. Это ужастно...