Например, делает запрос, и знаете, что у пользователя доступно 500 бонусов например.
Из них, человек например хочет потратить 300.
При генерации заказа, мы делаем выборку доступных бонусов у человека, и получаем следующий список
Бонус1 - доступно 40 бонусов
Бонус2 - доступно 50 бонусов
и тд
И по порядку делаем транзакции, чтобы покрыть 300 бонусов.
select i.* , o.sum_paid, transaction_id from bonus i
right join (select sum(value) as sum_paid, transaction_id from bonus where transaction_id is not null group by transaction_id ) o on i.id=o.transaction_id
если вам нужны только актуальные бонусы, которые можно потратить, то добавляете
where date_end>'2017-09-12'
having sum>sum_paid
Или же вы можете отображать все бонусы, даже сгоревшие в ЛК пользователя. Просто делаете проверку на дату и на кол-во потраченных бонусов.
Логика проста:
1) вы создаете чек для погашения
2) вы постепенно погашаете заказ доступными чеками (на уровне сервера), маркируя, что транзакция относится к основной записи (как раз это и есть метка родительского элемента). для понимания, вы можете в родительский элемент насильно записать id транзакции. тогда расчеты будет делать немного проще.
3) вы закрываете, или ничего не трогаете с чеками, которые пропали.
Ну хорошо, добавляете сколько бонусов потрачено из какого билета. не думаю что это проблема на стороне сервера вытащить карточки, доступные клиенту, и рассчитать на сервере все.
ид | бонусов пришло | родительский ид | дата создания | дата сгорания | тип транзакции
Например, создаете бонусные чеки
1 | 100 | null | 1 дек | 15 дек | бонусы
2 | 100 | null | 3 дек | 16 дек | бонусы
Далее, рассчитываетесь этими чеками , причем вам нужно будет указывать, к какому заказу это списание относится. нужно будет добавить в таблицу поля. 4 и 5 транзакции считаются на стороне сервера, и заполняются по мере списания определенных бонусов .
3 | -30 | null | 1 дек | 1 | оплата бонусами | заказ 1
4 | -70 | null | 1 дек | 1 | оплата бонусами | заказ 2
5 | -30 | null | 1 дек | 1 | оплата бонусами | заказ 2
Далее, мы можем выбрать доступные бонусные баллы, сделав join на таблицу, и получив сумму бонусов, дата которых еще не закончилась.
99% задач с которыми вы столкнетесь, сразу же после интервью потребуют подписать договор о неразглашении. Но задачи мне нравятся, я занимаюсь бэкенд на yii2.
jwwwe: Когда только начинал на fl?
По разным, задача была развить аккаунт. Проследить работы и их качеству вы можете по отзывам. К слову, вы можете подсчитать стоимость заказов за последние года и понять, какой процент fl у меня в работе. https://www.fl.ru/users/baydmitry/
awdemme: Вы правы по поводу топикстартера. Чувак еще не готов работать, а многие ему советую с белыми специалистами на upwork соревноваться в поиске заказов.
Как правило, на том же fl, работа делится на несколько этапов:
1) заказчик хочет проект под ключ. как правило, он будет смотреть на соотношение цены и отзывов специалистов. А еще немаловажно, чтобы человек умел все.
2) Команды ищут себе разрабов на аутсорс.
3) Ищут , кто сделает им черновую работу, например - верстка.
И чтобы начать на fl, надо иметь неплохие знания и начинать с черновой работы, беря маленькие заказы и набивая звезды.
