Нужна консультация пользователей скрипта

[celsoft 6 095]

http://dle-news.ru/2007/11/09/nuzhna-konsu...zovatelejj.html

[evolver 1]

Поясните плиз, в чем заключается нагрузка на MySQL на данный момент?

[kosen 3]

полагаю, что речь идёт о кол-вах запросов к БД... при выводе новости...

Но могу и ошибаться...

Изменено 9 ноября 2007 пользователем kosen

[celsoft 6 095]

Поясните плиз, в чем заключается нагрузка на MySQL на данный момент?

объясняю. Для того что бы показать вам новость, скрипт делает один запрос к MySQL но задействует несколько полей БД где просить выбрать из всей базы новость за определенный промежуток времени и который отвечает названию, сравнивая строки.

Новый вариант будет делать запрос, используя для поиска только один параметр и тот числовой, что гораздо гораздо быстрее. На маленьких базах это незаметно, на больших существенный плюс, также при большой посещаемости это большой плюс

[flo.mAster 7]

Мне не понравилось! http://site.ru/id новости/news.html

Лучше бы http://site.ru/id новости/а тут имя новости.html

Это моё мение!

[Владимир П 0]

flo.mAster, вообщем то так и есть

[flo.mAster 7]

если так и есть то сории

[evolver 1]

Поясните плиз, в чем заключается нагрузка на MySQL на данный момент?

объясняю. Для того что бы показать вам новость, скрипт делает один запрос к MySQL но задействует несколько полей БД где просить выбрать из всей базы новость за определенный промежуток времени и который отвечает названию, сравнивая строки.

Новый вариант будет делать запрос, используя для поиска только один параметр и тот числовой, что гораздо гораздо быстрее. На маленьких базах это незаметно, на больших существенный плюс, также при большой посещаемости это большой плюс

Все верно, однако не могу понять, что будет если смотреть так: site.zz/2007/ или так site.zz/2007/01/

И еще у Вас таблица POST индексируется по date и short_story, причем последний имеет очень тяжелую индексацию (для больших баз).

Смотрим дальше

// ################ Новость целиком #################

	if ($subaction != '' OR $newsid) {

		if (!$newsid)

			$sql_news = "SELECT id, autor, date, short_story, full_story, xfields, title, category, descr, keywords, alt_name, comm_num, allow_comm, allow_rate, rating, vote_num, news_read, approve, votes, access FROM " . PREFIX . "_post WHERE alt_name ='$news_name' AND date >= '{$year}-{$month}-{$day}' AND date < '{$year}-{$month}-{$day}' + INTERVAL 24 HOUR LIMIT 0,1";

		else

			$sql_news = "SELECT id, autor, date, short_story, full_story, xfields, title, category, descr, keywords, alt_name, comm_num, allow_comm, allow_rate, rating, vote_num, news_read, approve, votes, access FROM " . PREFIX . "_post where  id = '$newsid' LIMIT 0,1";


		if ($subaction == '') $subaction = "showfull";

	}

с этим все понятно - where id = '$newsid'

беда здесь - WHERE alt_name ='$news_name' AND date >= '{$year}-{$month}-{$day}' AND date < '{$year}-{$month}-{$day}' + INTERVAL 24 HOUR LIMIT 0,1";

ну и в реляционных базах конечно ID рулит

хотя я вот о чем подумал...

LIMIT 0,1

это зачем? лишнее телодвижение. Я думаю две новости с одинаковым alt_name не получится завести.

и вот еще что: если бы дата хранилась как timestamp то по целому числу найдет быстрее (как и индекс) нежели сравнение строк. Хотя я не могу говорить о том с какой целью заводилось поле дата в таком виде.

Изменено 9 ноября 2007 пользователем EvolVER

[celsoft 6 095]

Все верно, однако не могу понять, что будет если смотреть так: site.zz/2007/ или так site.zz/2007/01/

как было так и будет календарь использует данные пути

беда здесь - WHERE alt_name ='$news_name' AND date >= '{$year}-{$month}-{$day}' AND date < '{$year}-{$month}-{$day}' + INTERVAL 24 HOUR LIMIT 0,1";

от этого я и хочу избавится, но для этого нужно изменить URL. И этот запрос совсем не является бедой, он достаточно быстрый, но я хочу сделать еще лучше и быстрее

и вот еще что: если бы дата хранилась как timestamp то по целому числу найдет быстрее (как и индекс) нежели сравнение строк. Хотя я не могу говорить о том с какой целью заводилось поле дата в таком виде.

неверно в текущем поле дата есть полноценный ключ и он прекрасно задействуется для этого и написано date >= '{$year}-{$month}-{$day}' AND date < '{$year}-{$month}-{$day}' + INTERVAL 24 HOUR такая конструкция нужно чтобы ключи использовались, т.к. при выборке по функции ключи не задейстуются.

хотя я вот о чем подумал...

LIMIT 0,1

это зачем? лишнее телодвижение. Я думаю две новости с одинаковым alt_name не получится завести.

завести то как раз получится, ничего не мешает для этого и стоит LIMIT 0,1 чтобы не тянуть несколько новостей из БД

[max-money 0]

Уже давно для себя такое реализовал,

но перывать все было лень и я ограничиля только названием новости, вышло так http://energyua.com/2007/11/05/1022.html. Ну а дата по сути нужна, это дает возможность без запроса к базе вернуть нужный заголовок клиенту.

На одном изи своих сайтов я поисковикам практически всегда (задаю время устаревания) отдаю

header("HTTP/1.1 304 Not Modified");

, что еще в большей мере снижает нагрузку. Хотя про это я наверное уже на этом форуме писал.

В mysql LIMIT 0,1 эффективно срабатывает только при поле с индексом "UNIQUE", по непонятным мне причинам mysql все равно ищет все записи, но выводит одну.

По поводу даты - мне удобней работать с юникс-форматом.

Изменено 9 ноября 2007 пользователем max-money

[evolver 1]

Все верно, однако не могу понять, что будет если смотреть так: site.zz/2007/ или так site.zz/2007/01/

как было так и будет календарь использует данные пути

беда здесь - WHERE alt_name ='$news_name' AND date >= '{$year}-{$month}-{$day}' AND date < '{$year}-{$month}-{$day}' + INTERVAL 24 HOUR LIMIT 0,1";

от этого я и хочу избавится, но для этого нужно изменить URL. И этот запрос совсем не является бедой, он достаточно быстрый, но я хочу сделать еще лучше и быстрее

на большой базе он не может быть быстрым. Уберите хотя бы INTERVAL на базе в несколько сотен килозаписей и убедитесь как скорость подскочет.

Может проще завести еще поле

хотя я вот о чем подумал...

LIMIT 0,1

это зачем? лишнее телодвижение. Я думаю две новости с одинаковым alt_name не получится завести.

завести то как раз получится, ничего не мешает для этого и стоит LIMIT 0,1 чтобы не тянуть несколько новостей из БД

я просто не вникал, но получается:

а) дубляж

б) одна новость не будет доступна, если будут одинаковые alt_name и разные категории

неверно в текущем поле дата есть полноценный ключ и он прекрасно задействуется для этого и написано date >= '{$yea}-{$month}-{$day}' AND date < '{$year}-{$month}-{$day}' + INTERVAL 24 HOUR такая конструкция нужно чтобы ключи использовались, т.к. при выборке по функции ключи не задейстуются.

в данном случае подойдет только id, но это актуально только для больших баз, хотя, что называть большой базой. Если уж такая большая база, то использовать MSSQL хотя бы и с кластерами.

а если вопрос принципиальный, то я бы конечно поменял с даты на ид - ИМХО красивее - это раз, да и потом будет проще в дорисовывании всяких фишек - это два.

Мне кажется, что с таким изменениям нужно не соглашаться тока тем, у кого понатыканы моды и написанные не своими руками. А всем остальным должно быть все равно. Ради примера: не помню какой сайт (какой-то продажник-магнат авто в Москве) юзает данный движок, так ему пофигу, что ссылки на машины идут как на новость, а не сделано красиво, как в каталоге.

[celsoft 6 095]

на большой базе он не может быть быстрым. Уберите хотя бы INTERVAL на базе в несколько сотен килозаписей и убедитесь как скорость подскочет.

подсчет идет по индексу а не по базе

[dataman 0]

Я думаю две новости с одинаковым alt_name не получится завести.

Я извиняюсь , может и не втему .. Нопоповоду этого - наболело ..

К сожалению , мои пользователи , которые ведут свои разделы весьма просто могут создать запару месяцев 200 новостей - обзор газеты, или 150 - криминальная сводка , 400 - обьявление о торгах. пРИЧЁМ если дело в пятницу или суботу - то ктото торопиццо или наоборот , навёрстывает путём постинга новостей в колисиства 10 - 15. Из за этого приходится онключать ЧПУ, к новостям стучаться по id.

Посему - архиважно предусмотреть всёже ГЕНЕРАЦИЮ уникального алтернативного имени. Либо - тупо, в случае ошибки прибавлять к имени ID новости.

[xsong 1]

я против

[IT-Security 33]

Не против. Думаю, что можно делать два варианта. Просто два комплекта файлов.

Или руководство, как вернуть так, как было.

Ведь на больших сайтах поисковик уже прошёлся и теперь все страницы станут для него 404 =(

Так что думаю стоит подумать о двух вариантах.

Или о настройке в админке.

[1vic 0]

Skript ya eshe ne stavil a potomy hochy bistrii variant.

Spasibo, CelSoft!

[kosen 3]

Ведь на больших сайтах поисковик уже прошёлся и теперь все страницы станут для него 404 =(

Так ведь было сказано, что для уже добавленных новостей изменения не коснутся... только для новых материалов...

Так что с поисковиками проблем не будет... по идее...

[xsong 1]

всеравно лучше сделать 2 варианта также как с чпу и без чтобы можно было отключить...

лично я против нагрузки и так почти нет зачем его делать воздушным)

[eRED 0]

мне нравится вариант http://site.net/id.html, а вариант http://site.net/testovyj_zagolovok_novosti.html как-то громоздко смотрится. к тому же, на позиции в поисковиках, чпу влияет слабо либо вообще не влияет. поисковику до лампочки что в урл.

[IT-Security 33]

Ведь на больших сайтах поисковик уже прошёлся и теперь все страницы станут для него 404 =(

Так ведь было сказано, что для уже добавленных новостей изменения не коснутся... только для новых материалов...

Так что с поисковиками проблем не будет... по идее...

Каким образом?Ведь новости будут же продолжать запрашиваться по старой схеме, а в скрипте будет введена новая.

Можно конечно сделать второй реврайт и адресовать его на другой скрипт...Тогда наверное изменения не коснуться.

[kosen 3]

IT-Security,

Вот слова Целсофта:

Хочу сразу сказать что если вы переживаете за проиндексированные страницы в поисковиках, то не переживайте мы реализуем это так, что все ваши старые новости останутся неизменными, URL для них будет по старому принципу, только вновь добавленные новости будут иметь новый URL.

Я так понял, что нововведения НИКОИМ образом НЕ ЗАТРОНУТ СТАРЫЕ новости...

Изменено 14 ноября 2007 пользователем kosen

[Jam 0]

Лучше сделать так, чтобы парсировались и те и такие. Это реально, я знаю...

[IT-Security 33]

Ясен пень реально.

Два правила и два скрипта...

[kaliostro_den 2]

Я бы оставил и сделал новый вариант и дать этот выбор пользователю в админки или при установки.

[Danila 8]

Я бы оставил и сделал новый вариант и дать этот выбор пользователю в админки или при установки.

А что днлать тем, у кого двиг уже установлен и работает года 1.5?