Это не решает проблему, потому как rename(/image/kurica_s_gribami/2.jpg, /image/kurica_s_gribami/3.jpg). Все равно перезапишет старую картинку, которая была под именем 3.jpg
А сами запрос на пред и след. видео будут выглядеть как-то так:
На предыдущее
"SELECT * FROM `video` WHERE `id` < {$id_tekuschego_video} ORDER BY `id` DESC LIMIT 1"
На следующее
"SELECT * FROM `video` WHERE `id` > {$id_tekuschego_video} ORDER BY `id` ASC LIMIT 1"
Это скорее всего не тот код, который выводит ваше видео! Этот, скорее всего выводит список видео (например в категории).
Пока просто упростил ваш код...
function select_video($video, $lang, $start_pos, $perpage){
db_connect();
$query = " SELECT article.*,(SELECT COUNT(id) FROM comments WHERE comments.note_id = article.title_url AND comments.lang = '$lang') AS comments_count FROM video AS article WHERE article.`lang` = '$lang' ORDER BY article.`id` DESC LIMIT $start_pos, $perpage ";
Вроде такого?
Если вместе с ингредиентом прислан id - то это старый ингредиент - проверяем его на изменение и если изменен применяем UPDATE
А если id не прислан, значит INSERT его как новый в таблицу.
Не могу сообразить, что если ингредиент удалили при редактировании? Получается при получении на сервере ингредиентов, получаем те, которые у нас есть. проверяем и если in_array(каждый ингредиент в базе, полученные) == false, то удаляем его.
Наверное так?
Dave: Названия динамичны, они не выбираются из готового списка, а пишутся пользователем. Больше они нигде не используются, а если сделать так, как предлагаете вы - это дополнительный LEFT JOIN при каждом запросе рецепта.
по второму ответу... количество ингредиентов и сами ингредиенты могут меняться при редактировании, поэтому и выбрал вариант с удалением и добавлением...
Наверняка должен быть другой способ? Подготовленные запросы эфективны только при многократной вставке, причем если заменить эту многократную вставку обычным запросом с VALUES(1),(2),(3)
То и тут подготовленный запрос куда хуже справляется с задачей. Плюс они не удобны, постоянно приходится контролировать входящие, выходящие данные... Странно как-то все это...
Станислав Третьяков: Да, действительно, второй пример я не прочитал, посчитав его не относящимся к php из-за слова "Perl-совместимых" )))
Спасибо, в целом разобрался или хотя бы понял в какую сторону копать ))
Станислав Третьяков: Я про визуальный вид ссылки, которую предлагают в статье, вот она:
Фактически, она не сильно отличается от ссылки без ЧПУ. Пример: picone.ru/images/31-zahesyns.jpg
А по поводу поисковых систем... Разве они расчитывают глубину нахождения страниы не по ссылке?
Ведь страница
site.ru/catalog/
Явно ближе к главной нежели
site.ru/catalog/news/
Спасибо, за статью, довольно позновательно, но тут есть одна проблема с оптимизацией под ПС.
URL типа: http://server.com/модуль/действие/параметр1/значен...
Будет ровно в 2 раза дальше от главной странице по версии поисковых систем, нежели такой же, но через htaccess: http://server.com/модуль/параметр1/параметр2/параметр3/
причем, предложенный в статье вариант URL не на много отличается от урла без ЧПУ... Разве что вместо "=" стоит слеш, а "&" отсутствует.
