- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Полностью менять архитектуру БД и запросов. Извините, но это глупость на 1 загрузку 22 запроса.
---------- Добавлено 15.04.2016 в 15:44 ----------
Это отдельные таблицы что-ли?!
А как ещё?
Если нужно проверять ставил ли юзер лайк/дизлайк/репост?
Не ну конечно можно снизить все до 3х запросов:
Выбираем 10 новостей
Потом сразу же делаем выборку комментариев по всем новостям (WHERE `id`="1" OR `id`="2" OR `id`="3" ... )
Потом делаем сразу выборку на лайки/репосты/дизлайки по всем новостям.
Лайки/репосты/дизлайки харнить в 1 табилце.
Будет всего 3 запроса. Зато более тяжелые.
Но я думаю все равно желательно сделать кэширование, чтобы эти 3 запроса были не всгда, а только когда это требуется, верно?
Потом сразу же делаем выборку комментариев по всем новостям (WHERE `id`="1" OR `id`="2" OR `id`="3" ... )
эммм... а зачем вам для списка новостей все комменты? вам же только количество надо! которое хранится в самой новости...
и это очень лёгкий запрос ;)
Лайки/репосты/дизлайки харнить в 1 табилце.
про репосты я ещё как-то могу понять, но зачем разделять лайки и дизлайки?
эммм... а зачем вам для списка новостей все комменты? вам же только количество надо! которое хранится в самой новости...
и это очень лёгкий запрос ;)
Выводится новость и под ней последние 5 комментов сразу же, по этому нужно не только количество выбирать, но и сами комменты. А тут ещё получается, что коммент оставил какой-то юзер. И нужно ещё выбрать его фио + аватарку. Как правильно это все реализовать, чтобы запросов было минимум?
revered, я бы сложил всё это в json'е в кэш по id новости. это кстати идеальный пример для кэширования - изменяется гораздо реже, чем показывается
что-то с архитектурой не так у вас. мне кажется
Голосы и комментарии через AJAX добавляются.
Но проблема в том, что если закэшировать блок целеком, то когда он поставить лайк и обновит страницу (F5), то будет ему показано, что лайк не поставлен, т.к. ещё старая версия блока покажется.
Так надо, чтобы блок голосования целиком через аджакс работал, т.е. не только добавление голоса, но и показ текущего количества голосов должен через аджакс грузиться. Увеличение количества обращений к БД некритично, если они короткие - они кэшируются БД.
Или можно тянуть блок голосования вместе со страницей (как сейчас у вас), а после голосования писать результат в куку, далее при обновлении (или загрузке) страницы проверять наличие этой куки и если она есть и непустая, то подставлять в блок значение из этой куки. Правда тогда посетитель не увидит количество проголосовавших других посетителей во время его сессии. В общем как-то так.
Как правильно это все кэшировать?
Была идея кэшировать вообще всю страницу с новостями, и обновлять кэш раз в несколько минут. Но как быть с лайками и комментариями?
Попробуйте использовать тот же memcached, храните данные в ОЗУ кеше, а скриптом по крону обходите memcached данные каждые N минут, и сбрасывайте данные в MySQL таблицу. Даже если случится сбой, то потеряете данные за этот небольшой промежуток времени.