_Korn'у я ответил. Либо я не понял, что он имел ввиду, либо то, что он имел ввиду - чушь, либо он сам не понял, что он имел ввидуOriginally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]_Korn в принципе понял, постараюсь чуть детальнее объяснить почему так делать не стоит.Надеюсь, что неправ я
Вставлять надо не после, например, "двенадцатого", а после записи с конкретным id. В передать эти id в интерфейс не сложно, не так ли? Тогда нужно четыре запроса изменяюшие две, и добавляющие одну строку, как я и написал.Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]1. Возьмем готовую таблицу, организованную описанным тобой образом, состоящую к примеру из 100 записей. И тут юзер хочет вставить фотографию например под номером 55. Если ты при этом не используешь "нумерацию", твоему скрипту придется вначале вычислять куда её конкретно вставлять -- т.е. по сути пробегать с 1го элемента, до 55го (ну или с конца - неважно), выполняя для каждого по 1 запросу -- в чем же в итоге оптимизация?? вы при своей вставке выполнили N запросов возвращающих по 1 строчке, а я 1 запрос, изменяющий N строк.
Нет, я не буду это предлагатьOriginally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]2. Ты можешь предложить вариант: "А я возьму, действительно довалю order к своему динамическому связанному списку, и организую дин. структуру vector". Кстати напомню, что именно vector ускоряет вставку в середину, но никак не обычный list. Но даже используя такую структуру, вам все равно при добавлении нового элемента придется изменять счетчики для всех тех, которые идут после негоПо указанной причине.
Вектор ускоряет поиск, а не вставку.
Для того, чтобы ничего не перебирать в бд существуют индексы. Кстати в MySQL для первичных ключей они создаются автоматически. Так что поиск записи по первичному ключу - операция очень быстрая (вектор, агаOriginally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]1. А теперь давай не будем забывать, что у нас тут не массивы с указателями, а всего лишь таблица из БД. И один запрос работающий с сонтей строк отработает на порядок быстрее, чем сто запросов, каждый из которых работает с одной строкой. Только что касается моего запроса, то mysql специально оптимизирован именно для подобных простых запросов, пробегающих разок по всей таблице. А вот поиск 1й записи в таблице с данным индексом, её придется именно искать, т.е. перебирать несколько записей, для каждого такого запроса)
Возможно 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). Есть время?
Нужно стремиться к эффективности. Написать 4 строки вместо одной не так уж сложно.Originally posted by Scorched.dn.ua@Mar 22 2007, 11:08
[b]Вывод: БД предоставляет нам кучу возможностей, надо которыми разработчики парились годами, оптимизируя их, давая возможность конечному программеру просто использовать их не заморачиваясь с придумыванием своих способов хранения и пр., нужно стремиться к простоте
зы: Я тут столкнулся с такой вот программой, где порядок указывается вручную циферкой. Это ужастно...![]()