Какая логика поднятия объявлений в топ?

Question

[andrey_27081]

Имеется доска объявлений о продаже недвижимости. Имеется функция за определенную плату вывести объявление в топ на 3 дня.
По сути своей логика простая, но если этих премиум объявлений 1 000 из 100 000, не выводить же сначала все премиум (оплаченные) а потом обычные, тогда для не премиум объявлений просто не будет выбора, они будут где-то на сотых страницах если не дальше.
Как выстроить логику выборки объявлений, чтобы выводились несколько премиум (пусть 5), а потом обычные объявлений, чтобы премиум постоянно менялись, ну думаю это логично.

Comments

[Dmitry Bay]

Просто вверх поднять - это иметь поле времени и сортировать по этому полю. Если человек оплатил на 3 дня топ - ставить его как "+ 3 дня." Это логика как поднять вверх. И работать с ним вместо id. Это еще даст автообновление поста при необходимости раз в месяц.

Логика отображения объявлений в топ листе - делаете доп запрос по этому полю, и спец выборкой делаете рандом или иным способом отображаете топ лист.

[andrey_27081]

Dmitry Bay, Допустим я делаю рандомную выборку премиум объявлений в топ, но если их много, какова вероятность того, что в топе в итоге залетят все объявления.
Некоторые залетят 10 раз, а некоторые ни разу, а клиент платит деньги за это.

Может вести счет показов топ объявлений?
И при выборке учитывать этот момент, и брать в приоритет те топ объявления, которые показали меньше раз, таким образом по сути в топ со временем попадут все премиум объявления

[Dmitry Bay]

Некоторые залетят 10 раз, а некоторые ни разу, а клиент платит деньги за это.

Да, и это ваша задача. Сделать демократичный показ объявлений.

Может вести счет показов топ объявлений?

Обязательно. Это обычная логика. Причем, в статистику можете отправлять каждый показ, с набором важных факторов.
К примеру, самая простая табличка, уже может давать неплохую информацию о том, что показывают и как. Еще можно информацию о каждом клике сохранять. В простом варианте - через ссылку-редирект.
id | client_ip | ad_id | time | city(подгружается с внешнего сервиса по ip) | is_clicked

[Модератор]

Не надо ставить как можно больше тэгов. Лучше оставить один, но конкретный, с которым проблема.
См.п.3.1 Регламента. Также обратите внимание на п.3.6

Answer 1

[alexalexes]

Я бы построил бы структуру таблиц так, чтобы можно было бы выполнить такой запрос (по версии sql Oracle):

-- премиум выборка
select  1 as priv_type, -- тип привилегии 1 - премиум объявление
    C.*
from
(
  select B.*,
             dense_runk() over (order by B.user_id) as user_num, -- нумеруем авторов объявлений
             row_number() over (partition by B.user_id order by rownum) as add_num -- нумеруем объявление в пределах автора
  from
  ( -- достаем премиум объявления в случайной сортировке
     select A.*
       from A
     where premium_pay_date is not null and sysdate - premium_pay_date <= 3 -- условие попадания в премиум
  order by DBMS_RANDOM.RANDOM
   ) B
) C
where user_num <= 5 -- берем 5 авторов
   and add_num = 1  -- по одному объявлению от автора
union
-- обычная выборка
select 2 as priv_type, -- тип привилегии 2 - обычное объявление
         A.*,
        -- зануляем доп. поля от премиум, чтобы union работал корректно
        null user_num,
        null add_num 
  from A
  where premium_pay_date is null or sysdate - premium_pay_date > 3 -- можно исключить премиум из общей выборки, а можно не исключать
order by priv_type, Publication_Date desc