Ну или как вариант, если отойти от чисто SQL-ориентированного решения, для каждого юзера хранить строку (TEXT), в которой хранить пары вида =;=, и разбирать это в приложении самостоятельно.
Никакого огорода здесь нет, стандартное решение. Вот надо бы еще в UserPrice добавить индекс по product_id, и еще один по user_id, и движок сменить на MyISAM (если сейчас InnoDB).
@Snewer А можно точнее описать задачу? Что за категории и как они связаны с товаром? Что такое "прайс-лист"? У каждого пользователя есть "свои" товары или они общие для всех? Опишите это как-то конкретнее. И необходимые запросы - тоже, только насчет выборки по user_id все ясно, а второй запрос?
@yakushechkin@tsarevfs В последнее время вроде есть тенденция объектами называть и классы и экземпляры классов. Впрочем, для меня объект и экземпляр класса до сих пор одно и то же.
@likeapimp Кстати, Вам же таки все записи нужно получать в любом случае, судя по задаче. Получайте их просто вот так:
SELECT * FROM ... ORDER BY id
Первыми N - 3 записями в наборе будут те "все остальные", и последние три - самые новые. И не надо два разных запроса с LIMIT.
@Radiocity Причем здесь костыли? Если бы надо было выбрать ПОЛОВИНУ записей, тогда без более сложного запроса не обойтись. А зачем усложнять работу СУБД, если отбросить последние три записи НАМНОГО эффективнее в приложении? Может вообще всю бизнес-логику в БД размещать, в хранимых процедурах?
