я не шучу...)

Я тоже

😜

5,2

какой у тебя вопрос?)

Мне по структуре сказать организации, абстракции. Возможно стоит пакетом делать

Фото то было усатого сисовца Алисы?

Мне по структуре сказать организации, абстракции. Возможно стоит пакетом делать

ну конкретно вопрос задавай

Guthub.com/ko22009/volcenter

Фото то было усатого сисовца Алисы?

ДААА СУКА ДАААА

доступа на репо нет

Как так

а во есть

ты кривой линк скинул

редиректит)

github.com/ko22009/volcenter

а нахуя ты ЦРМ делаешь?

если их уже миллион

Думаешь, то, что есть для волонтёров подойдёт?

да

https://github.com/ko22009/volcenter/blob/master/app/Http/Controllers/Admin/ResponsibilityController.php#L15-L49

ЕБАТЬ, ЧТО ЭТО

Уволить его

Хаха, да, прогер один так предложил сделать.

ДААА СУКА ДАААА

Не матерись, палишься

Проект не коммерческий пока, о коммерциализации нужно подумать

Не матерись, палишься

5 функций в одной...

Эх, разделять и властвовать срочно!

Ну

а нахуя ты ЦРМ делаешь?

а че нет то

Issue на гите можете посоздаватт

че за тупой костыль ? https://github.com/ko22009/volcenter/blob/master/package.json#L9

может еще систему будем перестанавливать

Вечер в хату

Ребят, подскажите по реализации. Мне приходят CallBack запросы, от вк. О том что пользователь сделал комментарий, нужно реализовать работу с BlackList, чтобы игнорировать уведомления от нужных ID.

Как с точки зрения архитектуры, и скорости, реализовать это правильно?

Проще сделать доступные id

Не?

Была идея загонять строчки из blacklist просто через запятую в строчку таблицы, и просто проверять, через str_pos

Мы не знаем кто нас откоментирует

Наприме новый клиент в интернет магазине

Была идея загонять строчки из blacklist просто через запятую в строчку таблицы, и просто проверять, через str_pos

In_array тогда уже

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

О, тоже подойдет.

Гнать данные в json, и потом проверять in_array

Думаю от 1 запроса к бд скорость сильно не упадет

да уж лучше отедльную табличку завести с блеклистом where в итоге по индексу будет не хуже работать, чем in_array

или прочие

Медленее

Дополнительный запрос к аблице

и?

ну будут тебе эти 10 мс медленнее

а если у тебя в блеклисте будет 10000 записей

Ограничение будет в 20-30 записей

мало того, что PHP отожрет на 10000 элементов памяти несколько метров. так и еще искать их будет с линейной прогрессией

Блек лист чисто для администраторов, и персоналов

то есть, на может быть не больше 20-30 заблокированных пользователей? :)

31 не заблокируешь?

А зачем блокироваь

31?

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

ну не заблокировать, игнорировать. Суть небольшая

и вообще, по поводу одного этого запроса, я гарантирую, что есть очень медленные неиндексированные запросы с кучей неоптимальных джойнов и вложенностей. Но оптимизация именно на одном проверить есть ли в списке :) И для упрощения придумывать упрощение в количество записей.

на спичках экономите

на спичках экономите

От души в душу расписал

Да сколько раз обжигался :)

Ещё следует добавить что любое адекватное sql хранилище отработает не медленнее говнокода с стрпозом

Да сколько раз обжигался :)

Да я тут просто зашёл, а ты людей ставишь на путь истинный

Да сколько раз обжигался :)

Правда чо ща дичь там тебе впархивал чувак с синголтонами я не понял

как я понял хотел закэшировать массив моделек, чтобы не перезапрашивать в БД

Надо было ему пояснить за инмемори кэш

а чего-то я про него забыл. Где ж ты тогда был?

Лежал на диване

Это все хуйня

У нас на проекте вьетнамцы картинки в base64 в сессию вставляют

У нас на проекте вьетнамцы картинки в base64 в сессию вставляют

Зачем?

Зачем?

Выяснить так и не удалось

Выяснить так и не удалось

Не спросили? )

Не спросили? )

Ответ был по восточному туманен и закорючен)

У нас на проекте вьетнамцы картинки в base64 в сессию вставляют

Хоть не в куки

А ещё они при смене емейла у юзера удаляют все карты со stripe аккаунта