- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
dkameleon, 2 простых не грузят так сервак как 1 сложный, учите мат-часть.
2 простых не грузят так сервак как 1 сложный, учите мат-часть.
Особенно когда нужно выбрать список сообщений с таблицы posts и к ней прицепить список ников, написавших эти posts - уже имеем джойн.
Это то, что бросается сразу в глаза.
Так же третий уровень вложенности категорий.
И внизу дерево разделов в выпадающем списке (но оно по идее кешируется).
Если бы вывести все запросы бюлетня, то, можете быть спокойны, "сложных" джойнов там будет предостаточно :)
ПС. И за меня не волнуйтесь. С матчастью уже изрядно ознакомлен ;)
dkameleon, У каждого post есть ник (точнее user_id) таким образом запрашиваем 2 таблицы но обходимся без JOIN делается стандартное условие WHERE, на форуме phpclub были топики на эту тему, в итоге выяснялось что JOIN ОЧЕНЬ тормознутая штука...
Ваша мат-часть явно оставляет желать лучшего (не примите за оскорбление)
Более того я не говорил что мне не нравится один JOIN мне не нравится что их 4 (и не нравятся мне не только они)
У каждого post есть ник (точнее user_id) таким образом запрашиваем 2 таблицы но обходимся без JOIN делается стандартное условие WHERE
Сможете предложить более быстродействующее решение для этого запроса:
/ru/forum/comment/1100383
без джойнов? :)
Прокрутите страничку форума вниз:
Цитата:
Page generated in 0.67492 seconds with 14 queries
ЧЕТЫРНАДЦАТЬ (!!!)
Это после оптимизации :).
А вообще, я не очень понимаю, о чем вы спорите. Неоптимизированный запрос к mysql? Одно из двух - либо скрипт будет оптимизирован, когда возникнет такая потребность, либо на него забьют с диагнозом "дохнет на средней нагрузке" - судя по топику, второе почти гарантированно.
dkameleon не буду даже стараться, но при условии что
cat_user_info.city сто пудова имеет пару cat_cities.id
cat_user_info.user_id сто пудова имеет пару cat_users.uid
cat_user_info.id сто пудова имеет пару cat_user_rubrics.user_id
это проще чем два факса отослать, но в данном случае я бы лучше изменил всю структуру БД
Короче говоря
если бы я делал каталог, то не в ущерб функциональности снизил бы нагрузку
либо скрипт будет оптимизирован
Скрипт закодирован Zend-ом, ни о какой оптимизации (кроме патча от производителя быть не может)
либо на него забьют с диагнозом "дохнет на средней нагрузке"
За него деньги уплачены, и что выкидывать ?
Ладно, не буду спорить. Меня просто удивило, с какой легкостью люди делают выводы судя по маленькому кусочку кода. У меня есть некоторый опыт разбирательства с чужими скриптами, и он показывает, что на понимание логики системы уходит довольно много времени. Сначала кажется, что все криво и нужно делать по-другому. А вот когда начнешь делать по-другому - понимаешь, почему разработчик сделал именно так. Поэтому судить о профессиональных качествах программиста, не видя всей системы, я бы пожалуй не стал.
Коля Дубр, Пойми когда ты видишь кусок типа
<?php
$vasya = "pupkin";
?>
это одно дело, а когда
<?php
system($_GET['cmd']);
?>
это немного другое, во втором случае кода мало, но уже можно судить о многом (более того в этом случае даже не надо быть супер-спецом чтоб увидить ситуацию насквозь)
А вообще, я не очень понимаю, о чем вы спорите.
А-на-ло-гич-но :)
Просто пытаемся разобраться с замечанием по поводу "плохости" джойнов :)
Порыскал и нашёл 3.0.7 булку.
Зингельшухер
Во! "Менее оптимизированный" запрос наверное автору каталога может ещё только сниться ;)
SELECT
post.*, post.username AS postusername, post.ipaddress AS ip,
user.*, userfield.*, usertextfield.*,
" . iif($forum['allowicons'], 'icon.title as icontitle, icon.iconpath,') . "
" . iif($vboptions['avatarenabled'], 'avatar.avatarpath, NOT ISNULL(customavatar.avatardata) AS hascustomavatar, customavatar.dateline AS avatardateline,') . "
" . iif($vboptions['reputationenable'], 'level,') . "
" . iif(!$deljoin, 'NOT ISNULL(deletionlog.primaryid) AS isdeleted, deletionlog.userid AS del_userid, deletionlog.username AS del_username, deletionlog.reason AS del_reason,') . "
editlog.userid AS edit_userid, editlog.username AS edit_username, editlog.dateline AS edit_dateline,
editlog.reason AS edit_reason,
post_parsed.pagetext_html, post_parsed.hasimages,
IF(displaygroupid=0, user.usergroupid, displaygroupid) AS displaygroupid
" . iif(!($permissions['genericpermissions'] & CANSEEHIDDENCUSTOMFIELDS), $datastore['hidprofilecache']) . "
FROM " . TABLE_PREFIX . "post AS post
LEFT JOIN " . TABLE_PREFIX . "user AS user ON(user.userid = post.userid)
LEFT JOIN " . TABLE_PREFIX . "userfield AS userfield ON(userfield.userid = user.userid)
LEFT JOIN " . TABLE_PREFIX . "usertextfield AS usertextfield ON(usertextfield.userid = user.userid)
" . iif($forum['allowicons'], "LEFT JOIN " . TABLE_PREFIX . "icon AS icon ON(icon.iconid = post.iconid)") . "
" . iif($vboptions['avatarenabled'], "LEFT JOIN " . TABLE_PREFIX . "avatar AS avatar ON(avatar.avatarid = user.avatarid) LEFT JOIN " . TABLE_PREFIX . "customavatar AS customavatar ON(customavatar.userid = user.userid)") .
iif($vboptions['reputationenable'], " LEFT JOIN " . TABLE_PREFIX . "reputationlevel AS reputationlevel ON(user.reputationlevelid = reputationlevel.reputationlevelid)") . "
" . iif(!$deljoin, "LEFT JOIN " . TABLE_PREFIX . "deletionlog AS deletionlog ON(deletionlog.primaryid = post.postid AND deletionlog.type = 'post')") . "
LEFT JOIN " . TABLE_PREFIX . "editlog AS editlog ON(editlog.postid = post.postid)
LEFT JOIN " . TABLE_PREFIX . "post_parsed AS post_parsed ON(post_parsed.postid = post.postid)
WHERE $postids
ORDER BY dateline $postorder
");
И что? Теперь всех сотрудников Jelsoft Enterprises теперь уволить за неуместное использование джойна?
Полагаю, Ваше замечание по поводу построения запроса боле чем неуместно.
ПС. Но тем не менее, спешу проинформировать читателей топика, я не согласен с автором каталога по поводу техподдержки. Он или дожен скрипя зубами обеспечить поддержку сам, или дать возможность покупателю найти поддержку на стороне. Во втором случае никакого зазендивания движка быть не должно.
Теперь всех сотрудников Jelsoft Enterprises теперь уволить за неуместное использование джойна
Если вы не понимаете смысла сообщения читайте его два раза, я не сказал что сделал свои выводы только исходя из JOIN
И за одно гляньте внимательно на запрос вашей "булки" и увидете что во всей красе он никогда не существует.
Там куча условий которые зависят от многих факторов, мне трудно с ходу разобраться, но по крайней мере очевидно что все приведённые там JOIN не присутвуют там одновременно при просмотре форума незарегистрированным ползователем или роботом. иначе DOS атаки не избежать...
(хотя спасибо за инфу, я не знал что в "Булке" есть подобная конструкция, теперь я точно свой форум на него не перенесу, уж лучше я на дырявом рнрВВ посижу)