hYPER-ok: Ребят, подскажите как хранить похожие новости к определенным постам? Предполагаю что-то типа такого: id_post, id1,id2,id3,id4,id5, title1,title2,title3,title4,title5, date1,date2,date3,date4,date5 в отдельной таблице. id_post - поле с ID постом к которой будут похожие новости id1-5 - поля с ID похожих новостей title1-5 - поля с названиями похожих новостей date1-5 - поля с датами похожих новостей. Выбирать LEFT JOIN`ом к определенному посту, если есть такие. 1. Правильно или нет? Если нет, то, пожалуйста, поправьте. 2. Сложны ли такие запросы? (использование индексов конечно).
создается еще одна таблица sim_post с двумя колонками id_post и id_sim_post . в первой колонке id равно "главной" новости, вторая колонка - id "похожей" новости. все новости хранятся в одной таблице. в селекте просто связываете основную таблицу на себя же через эту доп таблицу и никаких ограничений на кол-во похожих новостей
Возможно другой запрос еще обращается к этому аласу t.
t доступна только в пределах этого запроса
---------- Добавлено 07.03.2012 в 22:01 ----------
а зачем там вообще подзапрос????
"order by datetime asc" вполне в пхп делается, записи-то уже отсортированы. всего делов-то, выводить массив не с начала в конец, а с конца в начало
Убираю этот код, все падает... Подскажите что дальше делать
вот это надо оставить
Ребят, подскажите как хранить похожие новости к определенным постам? Предполагаю что-то типа такого: id_post, id1,id2,id3,id4,id5, title1,title2,title3,title4,title5, date1,date2,date3,date4,date5 в отдельной таблице.
id_post - поле с ID постом к которой будут похожие новости
id1-5 - поля с ID похожих новостей
title1-5 - поля с названиями похожих новостей
date1-5 - поля с датами похожих новостей.
Выбирать LEFT JOIN`ом к определенному посту, если есть такие.
1. Правильно или нет? Если нет, то, пожалуйста, поправьте.
2. Сложны ли такие запросы? (использование индексов конечно).
создается еще одна таблица sim_post с двумя колонками id_post и id_sim_post . в первой колонке id равно "главной" новости, вторая колонка - id "похожей" новости. все новости хранятся в одной таблице. в селекте просто связываете основную таблицу на себя же через эту доп таблицу и никаких ограничений на кол-во похожих новостей
там память занята на 50% только
Сейчас пескаря уходят еще и на переключение между процессами
их там двадцать штук... были бы тыщи - стОило подумать, а так смысла нет
ищите общие модули (напр. TinyMCE)
недавно был сломан TimThumb - а он ставился везде, на любой движок
О хоть кто то нашелся с подобной проблемой)))
шесть страниц /ru/forum/697738
А смысл? Сегодня js, завтра css, послезавтра html, через год mp3
Нужно более глобально проблему решать
смысл есть, т.к. глобально проблему не решить.
дырки, вирусы будут всегда, по-крайней мере пока используется фон Неймановская архитектура
любая защита - это всегда комплекс мер
удалите дубликаты через delete а не через создание индекса. буквально намедни тут тема пробегала
для поиска уязвимостей Acunetix, Havij