Запросы с исключением
 

Есть таблица юзеров as U (в таблице 2 миллиона записей)
Есть запрос который выводи в произвольном порядке 100 записей из таблицы юзеров, для конкретно выбранного юзера (U.id).
Нужно запомнить что что для выбранного юзера U.id мы уже показывали вот этих 100 рендомных юзеров, и как исключение при следующих запросах их не отображать.

Стандартный вариант, завести еще одну таблицу as D и туда сувать, тех кто попал под рендом и кому этот рендом отобразился, но как строить запрос с исключением? and U.id != D.uid and ...

Либо завести еще одно поле в таблице U.lockField (text) и туда для конкретно выбранного плюсовать чрез разделитель id тех кого уже отобразили, а потом делать выборку с исключением через like но тогда не будут фурыкать индексы, и база будет очень разростаться при большем количестве запросов.

Как лучше реализовать подобное?

Это смотря какие задачи стоят.
Больше никогда в жизни не отображать уже показанные ID или успокоиться на текущей сессии

А что за база? Копайте в сторону подзапросов

База на postgreSQL.

membrilius Да никогда в жизни...
Может за исключением если записи в таблице "закончатся" которые еще не отображались, тогда всё очистить и начать заново. В реале это все равно где-то хранить и выбирать надо...

leofit Спасибо, возьму на заметку как вариант...

А смысл в исключении?

Смысл в не повторяться. Работая при этом с большим количеством данных.

Раз данных много, а выборка небольшая, вероятность повторения не очень высока. Лично я бы не стал заморачиваться в угоду производительности. Конечный пользователь не особо-то и заметит повторения.

Конечно хранить в базе для каждого юзера 1 999 999 потенциальных IDшников и при выборки ещё в них рыться, это жесть.

Можно подумать, над псевдо-"псевдо случайной" выборкой. Выбирайте не просто хаотично разбросанные 100 юзеров по таблице из 2млн полей, а интервал. Допустим:
Можно дополнять любыми условиями.
Потом смотрите ID последней записи и пишите в базу просмотренный интервал. Более мы его не используем. Минусы только что записи идут по порядку. Если юзер будет удалён из базы, то интервал немного съедет по-этому надо сделать доп. поле delete и выбирать с учетом его. И для интервалов должны быть жесткие условия.

Интервалы можно объединять для экономии места.

Может глупое решение, но брать "начальное число" случайным. Например, 63. И выводить юзеров с идами 63-163.

membrilius да тема =) это пока наилучший вариант... может получится обойтись без рендома...

Psycho Tiger В идеи что-то есть... но не подойдет потому как при выборке еще куча условий...

Всем спасибо!