Привет. А можете поконкретнее объяснить, что нужно вам выбрать. Как-то я не очень понял. Вас не устраивает, что для business_day = 1 у вас выбирается запись, где week_day = 2? Про вот это тоже не вкурил -- business_day = 7, имеет week_day = 1, а не 9.
Евгений Конкин: Ясно. Отмечу только, что слайдер из 1000+ нельзя делать. Смысла мало в нем. Всегда есть тематика, которая ограничивает набор. Вам надо найти такую тематику. К примеру, фильмы за последние 6 месяцев. Или 3 месяца. В любом случае должен быть цикл. Иначе это не слайдер. А вы представляете себе слайдер из 1000 картинок? Пользователь просто устанет их все просматривать, или же искать нужный (если есть ручное переключение). Да 100 картинок уже напряжно переключать)). По аяксу, к примеру, вот у вас есть 100 картинок для слайдера. Вы просто можете сразу все подгрузить в фоне. Либо при каждом аякс запросе кешировать картинки. Как только они все подгрузятся, то аякс уже не будет работать.
banny_name: А вам и не нужно знать название тегов. Теги определяются по <текст>текст>. Я вам в примере указал теги, чтобы наглядно было как должен работать алгоритм. Грубо говоря у вас будет цикл, который будет искать n-й тэг, n-1, n-2...1-й тег. Ну... в теории это так). Я не проверял, но предположил, что так может работать. А Чтобы алгоритм не зацикливался, вы должны в найденных строках искать тег body. Если такой есть, значит выходить из цикла.
Вячеслав Беляев: Аха. Было бы более продуктивно. Сейчас просто я на основе вашего запроса мудрю с условиями. А на основе приближенных данных и структуры таблиц более ясно будет. Попробуйте так (ag.`group` = 3 OR ag.`group` = 5) AND u.`group` NOT IN (3, 5) -- это только по второму пункту по идее.
Вячеслав Беляев: Есть вопрос, а вот это условие: список анкет, которые отправлены к группе "3" или "5" -- где оно в вашем запросе? Как я понял, вот это условие (u.`group` = 3 || u.`group` = 5), говорит только, что пользователи имеют группу 3 или 5.
Вячеслав Беляев: Нужны примеры вывода запросов и сами запросы. Лично мне сложно что-то вам посоветовать, так как я даже не вижу проблему вашими глазами.
Alexey Sh: Нет. дублирующиеся ключи будут просто игнорированы. Вы получите просто предупреждение, но не аварийную ошибку. Вообще говоря, зачем вам такой "неуникальный" ключ? Сделайте сквозную генерацию primary key. Меньше проблем будет).
А у вас в экшенах параметры не передаются от post/get? Надо обязательно из POST читать? Еще странно, что у вас в каждом экшене $this->logged(); проверка идет. Может это можно было один раз на входе класса проверить? Это так мысли в слух)
Alexey Sh: А вам какая разница игнорирует он или нет? Вы же это никак не обрабатываете, насколько я понял. Да это же разовая операция импорта у вас, если я верно понял. Storage_table и table просто две таблицы для объединения.
