Достаточно сложный вопрос, но может кто поможет. Если кто-то занимается

Question

Достаточно сложный вопрос, но может кто поможет. Если кто-то занимается

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

Пусть есть таблица
id, user_id, match_id, bet_id (тип ставки, int), value(float), win(bool, дефолтно Null, тк ставка не рассчитана)

Человек может сделать ставку как на победу первой команды в матче, тогда bet_id (условно, будет 1), а поле value пустое (либо можно 0 вписать). Однако, если юзер ставит на тотал мячей больше (или что-то подобное, например фору, что имеет динамическое значение), то bet_id пусть будет 325, а value может варьироваться в пределах от 0.5 до бесконечности.
Взято специально полуторное значение, чтобы не было возвратов ставки.

Как одним запросом можно сделать update поля win на победу (true) и поражение (false) на основании типа bet_id, и если тип bet_id требует уточнения поля value, то уточнить, сравнить поле value с выданным мной значением и решить true или false

Как лучше такое провернуть? Если одним нельзя, то как лучше?

#backend #devops #pgsql #programming #russian

0

02.06.2022

4 ответов

14 просмотров

Gamer's Diary Project Автор вопроса

Alexey Erpilev
case конструкция годится?

Я думал над case. Что-то типа Update table SET win=CASE WHEN bet_id in () THEN true WHEN bet_id in () THEN false ELSE null. Но, как сюда ещё внедрить проверку id и заглядывание в value? У меня на один матч могут быть: фора одной из команд, тотал угловых, тотал, мячей, фора по голам итд. Для каждой ставки своё пограничное "победное" значение, как их подставить и заставить проверять? Желательно максимально эффективно

0

02.06.2022

Gamer's Diary Project Автор вопроса

Ещё рассматриваю такой вариант: у меня 15 типов ставок (bet_id). Можно на каждый матч сделать 15 запросов, где уже добавить CASE, ну и там где надо использовать поле value, где не нужно - не использовать. Не знаю, получится ли так быстрее...

0

02.06.2022

Юра

Gamer's Diary Project
Ещё рассматриваю такой вариант: у меня 15 типов ст...

Я считаю, что если есть 15 разных типов сущностей (которым приходится храниться в одной таблице), то для обработки каждого типа сущностей должны быть свои запросы. Есть преимущества: 1) можно в процессе развития системы гибко добавлять/исключать типы сущностей, не боясь нарушить работу остальных 2) можно выборочно обрабатывать сущности каждого типа. 3) Будет много небольших запросов, которые сравнительно проще писать, отлаживать, изменять или переносить, если потребуется.

0

02.06.2022

Alexey Erpilev · Accepted Answer

Alexey Erpilev

case конструкция годится?

0

02.06.2022

172 похожих чатов

Достаточно сложный вопрос, но может кто поможет. Если кто-то занимается

4 ответов

Похожие вопросы