Всем привет.

Такая задача: есть пользователи, им выдаются некоторые бонусы. Пользователь может активировать бонус, т.е. у бонуса есть статус.
И есть нюанс - у каждого пользователя активным может быть только один бонус. Далее активный бонус либо отменяется, либо используется, т.е. в дальнейшем статус его изменяется либо по решению пользователя, либо после срабатываения некоторых условий.

Как сделать такое ограничение в базе ?

Идеально быть бы сделать partial index , как у конкурентов:



Но у нас такого нет, увы.
Есть CORE-3384 , но там как-то бесперспективно всё.

Просматривается 2 некрасивых решения:
1. Завести отдельную табличку active_bonuses, обеспечивать уникальность с ее помощью.
2. Сделать вычисляемое (в триггере) поле uniq_status, что-то типа case when status = 'active' then status end, и повесить уник на (user_id, uniq_status)

Оба решения не нравятся, потому что требуют заводить какие-то дополнительные объекты, являющиеся, по сути, костылями.

Точно, есть же computed by. Забыл. Спасибо :)

Ну вы тут накидали, стоило отойти ненадолго ... :))

Уникальность нужна только для активного бонуса. Неактивных, например, выданных пользователю, но не активированных им, может быть сколько угодно. В том числе и при наличии активного.

Старый плюшевый мишкаСисдба МастеркеевичОба решения не нравятся, потому что требуют заводить какие-то дополнительные объекты, являющиеся, по сути, костылями.

При активизации любого бонуса у юзера сброс молча в inactive предыдущего его активного в before триггерах по бизнес-логике не прокатывает?
Триггеры не помогут, ибо тимлид их не любит, поэтому у нас их нет. Вообще. Как и процедур.

WildSeryСисдба МастеркеевичТриггеры не помогут, ибо тимлид их не любит, поэтому у нас их нет. Вообще. Как и процедур.Каким образом тогда активируется бонус? Кто деактивирует предыдущий активный?По сути сам пользователь. У него спрашивают, типа "у тебя уже есть активный бонус, активируешь новый - убьешь старый, готов ?", ну и "внутри" потом сначала деактив старого, потом актив нового.


KreatorXXIСисдба МастеркеевичТриггеры не помогут, ибо тимлид их не любит, поэтому у нас их нет. Вообще. Как и процедур.

Вся логика на клиенте? Зачем тогда париться насчёт этого хитрого индекса?Чтобы в базу нельзя было засунуть непотребное.


Dimitry SibiryakovСисдба МастеркеевичУникальность нужна только для активного бонуса.

Повторяю медленно: в чём проблема сделать этот бонус полем в таблице пользователей?Мысль понятна. Только не в пользователей, а в аккаунты (я "забыл" упомянуть о них, для упрощения описания задачи), ибо у пользователей есть аккаунты, для каждой поддерживаемой валюты. Кроме того, это не решит исходную проблему - т.е. не обеспечит единственность бонуса в статусе "активный".


Старый плюшевый мишкаСисдба МастеркеевичТриггеры не помогут, ибо тимлид их не любит, поэтому у нас их нет. Вообще. Как и процедур.

Аааа... Бег в мешках с барьерами по подвесной проволоке? Уважаю. Почти. Ибо индексы он таки любит, прослабел. Самурай без меча подобен самураю с мечом, но только без меча.Целиком и полностью разделяю и поддерживаю :) Но есть некие реалии, с которыми приходится считаться.

pastorСисдба МастеркеевичНу вы тут накидали, стоило отойти ненадолго ... :))

Уникальность нужна только для активного бонуса. Неактивных, например, выданных пользователю, но не активированных им, может быть сколько угодно. В том числе и при наличии активного.


Я тебе за бонусы еще один умный вещь скажу.

Завтра придут и потребуют сроки протухания бонусов. Как активированных, так и неактивированных.
А послезавтра - сроки начала активации оных.

И еще вчера - текущее сальдо этих самых бонусов.Всех соломок не постелить, это понятно.