но бл за это меня и обосрали

Насколько я помню, тебя не за это обосрали Тебе вполне логично говорили, что не хорошо во вьюхе вытягивать откуда-то значения Если вьюхе нужно это значение, пусть контроллер передаст его

Насколько я помню, тебя не за это обосрали Тебе вполне логично говорили, что не хорошо во вьюхе вытягивать откуда-то значения Если вьюхе нужно это значение, пусть контроллер передаст его

+

Он даже сути не понял

Доку бы прочитал от корки до корки

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

Не могу понять как сделать "переливание" участников.

Например заходит человек по реф ссылке к id-1 , но у него уже есть 3 реферала и больше он принять не может,как закрепить его за следующим человеком(тот кого пригласил id-1) ниже по иерархии? При условии что у него есть свободные "места".

Например заходит человек по реф ссылке к id-1 , но у него уже есть 3 реферала и больше он принять не может,как закрепить его за следующим человеком(тот кого пригласил id-1) ниже по иерархии? При условии что у него есть свободные "места".

Так это неправильно. Рефералом должен быть прегласивший и только ему можно начислять балы. Всем вышестоящим их подсчитывать потом нужно

Так это неправильно. Рефералом должен быть прегласивший и только ему можно начислять балы. Всем вышестоящим их подсчитывать потом нужно

баллы начисляются 6 уровням по иерархии

Да, но больше всего баллов получит пригласивший

не совсем

А все вышестоящие будут получать часть от того, что останется

% по иерархии расписаны в сотвествии с маркетинговым планом

почти у всех по 5%

А у пригласившего?

и даже у него 5%

но когда id -1 пригласит(или получит) человека ,который будет на 5 уровней ниже него тогда с него он получит 50%

На МММ работаешь?

я не сильно шарю во всей этой движухе,дали ТЗ делаю

ну или стараюсь делать..

А проблемы в чем? Смотришь у владельца рефералов, есть ли свободное местоя если нет та же самая операция у его детей

Только кажется если иерархия если большая, то пройтись по всем накладно

ну

за все 6 уровней id-1 сможет набрать себе 1092 человека максимум

А если nested sets ?

с которого ему будут падать деньги

Там вроде без рекурсии

я то и дерево рефералов храню в mysql как ref_1 ref_2 ref_3.. ref_6

так.. если без рекурсии просто сделаю всё на else if и протестирую на адекватность логики

так.. если без рекурсии просто сделаю всё на else if и протестирую на адекватность логики

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

Но критерием остановки поиска будет наличие у пользователя свободного места для реферала

Ещё советую сразу подумать, что будет, если пользователя удалить (если логика приложения разрешает)

я то и дерево рефералов храню в mysql как ref_1 ref_2 ref_3.. ref_6

Во первых погугли про nested sets, materialized path, во вторых как на счёт хранить кол-во рефералов у каждого юзера? В случае mp тебе что бы найти свободное место достаточно будет поискать в базе типа: WHERE referals_count < 3 and materialized_path LIKE "1.2.6.9...%"

мне тоже кажется что тут одно из nested sets, materialized path

Во первых погугли про nested sets, materialized path, во вторых как на счёт хранить кол-во рефералов у каждого юзера? В случае mp тебе что бы найти свободное место достаточно будет поискать в базе типа: WHERE referals_count < 3 and materialized_path LIKE "1.2.6.9...%"

если ты хочешь nested sets - подумай почему ты вообще хочешь хранить деревья в mysql.

в остальных случаях комбинация adjacency list + materialized path (для сортировки) является довольно универсальным решением.

что до реферелов - в mysql вариантов не много, а в postgresql можно было бы хранить цепочку в jsonb и не париться

p.s. mysql 8 поддверживает рекурсивные запросы, так что можно многие вещи проще делать.

но если количество рефералов не ограничено - я бы предпочел хранить их вообще в отдельной СУБД (типа neo4j).... хотя если пользователей пара тысяч то пофигу конечно

когда создавал подобное дерево уже советовали 3 метода хранения. После долгого чтения информации в итернете ничего лучше чем хранить у пользователя предыдущие его 6 уровней не нашел.

когда создавал подобное дерево уже советовали 3 метода хранения. После долгого чтения информации в итернете ничего лучше чем хранить у пользователя предыдущие его 6 уровней не нашел.

тут зависит от задачи. В плане рефералки у нас условия следующие: - редко создается связь (при регистрации пользователя по сути) - практически никогда не меняется - довольно часто кверится цепочка рефералов (например при кэшауте, расчете бонусов или для чего у тебя там рефералка)

то есть в целом в 90% случаев рефералку можно хранить просто как jsonb массив айдишек

Ребят пишу бот telegram на php, такая проблема с реферальной ссылкой. Кидаю другому юзеру, только спустя 30 секунд бот ему отвечает и вылазиет меню если писать просто команду /start то все быстро а если с рефералки кидать такая шняга

Уже все просмотрел вроде все нормально

А проблема не уходит(

кто-нибудь знает группу, где бы бигдату обсуждали?

https://t.me/hadoopdev

спасибо. Они чисто на Hadoop заточены?

Ребзя, небольшой офтоп. Такой вопрос, как правильнее делать если работать с контейнерами. Один контейнер с MySQL и там базы под сервисы. Или для каждого сервиса свой контейнер с MySQL

Глянь laradock

Можно прям его и взять

ну имхо это перебор

разве как основу брать, и потом вычищать лишнее

по топику вопроса - зависит от того, что разрабатываешь

Да я про то и говорю

если у тебя в контексте одного проекта много сервисов, работающих с базой - пускай один контейнер для базы

если в разных проектах - тогда держи по контейнеру на каждую базу каждого проекта

Взять за основу и сделать кучу баз, если так требуется

Взять за основу и сделать кучу баз, если так требуется

ну не знаю, я себе свое собрал замечательно)

С точки зрения безопасности может стоит много контейнеров иметь

С точки зрения безопасности может стоит много контейнеров иметь

поясни?

Доступ к одной базе не даёт доступ к остальным

да дело даже не в этом, просто для деплоя ты ведь не будешь все наружу выкладывать (все базы)

разве что если у тебя локальная разработка и больше докер нигде не применяется.... но имхо все равно оверхед + с docker-compose возиться придется

ERROR: S client not available

Тут на любителя

много контейнеров с базами кушать не просят, тем более, если это одна и та же СУБД той же версии - даже место будет только на данные тратиться

Не пойму о чем ты)

Данные ведь не в контейнере хранятся. Деплоить придется только docker-compose. Копипастом можно любое количество баз сделать и соединить их как душе угодно

Сборку можно простым скриптом сделать сборкой контейнеров. Обновление тоже толпой в любое время

Если решит сервис выкинуть на другой сервер, то легко будет взять с собой только один инстанс базы

но зачем, если можно просто поднять N контейнеров и не любить себе мозги?)

ну и обозначать контейнер с базой как-то придётся для композа

ребят, посоветуйте, какую дату поставить значению "активен до", если нужно указать "навсегда"?

в mysql

ребят, посоветуйте, какую дату поставить значению "активен до", если нужно указать "навсегда"?

переименуй поле в disable_at и сразу поймешь)

переименуй поле в disable_at и сразу поймешь)

фишка в том, что нужно указывать активен с и активен до

фишка в том, что нужно указывать активен с и активен до

ну ок, null норм

ну ок, null норм

а есть другие варианты? какая-то точка во времени, которую вряд ли будут использовать. максимальное значение timestamp, может быть?

а есть другие варианты? какая-то точка во времени, которую вряд ли будут использовать. максимальное значение timestamp, может быть?

костыль же ... null - обозначает, что ограничение по времени активности не задано

Че вам null не угодил, зачем ищите экстремальные значения?

запрос вытягивания этих записей уже очень сложный. если бы можно было вытягивать простым сравнением < или >, мне бы упростило работу очень. сейчас же везде придется ставить OR .. IS NULL

запрос вытягивания этих записей уже очень сложный. если бы можно было вытягивать простым сравнением < или >, мне бы упростило работу очень. сейчас же везде придется ставить OR .. IS NULL

ну можешь воткнуть 2038 год, лол

запрос вытягивания этих записей уже очень сложный. если бы можно было вытягивать простым сравнением < или >, мне бы упростило работу очень. сейчас же везде придется ставить OR .. IS NULL

запрос каких записей? ... те которые активны сейчас?

или 1970-01-01 01:00:00 наборот

Нужно больше костылей)

запрос вытягивания этих записей уже очень сложный. если бы можно было вытягивать простым сравнением < или >, мне бы упростило работу очень. сейчас же везде придется ставить OR .. IS NULL

Если приложение нормально организовано, то этих "везде" будет единицы

ребят, посоветуйте, какую дату поставить значению "активен до", если нужно указать "навсегда"?

ну поставь лет на 100 вперед и не парься

текущий год + 100 лет

ну храни активных бесконеночно в специальном месте в виде списка

да я думал есть какой-то общепринятый костыль хд

ну если хочешь без костылей

ребят, посоветуйте, какую дату поставить значению "активен до", если нужно указать "навсегда"?

null - прекрасное решение

то заведи поле специальное пользователю

типо активен бесконеночно начиная с даты

либо у тебя "активен до" это составное значение из двух полей