Как организовать и хранить конфиг по каждому пользователю, чтобы что-то делать один или несколько раз?
Необходимо при авторизации пользователя, показывать тот функционал, который он еще не видел, один или несколько раз.
К примеру: сверстали новое модальное окно с новым функционалом, и нужно показать его всем, далее при закрытии окна или обновлении страницы больше не показывать его.
Или что либо либо еще добавилось: какой нибудь блок, который когда человек ознакомился нужно больше не показывать.
Как хранить состояния по каждому пункту. Был вариант делать поля вида: user_id, par1, par2. Был вариант хранить по каждому игроку объект в виде json {par1: false, par2: true}. Но как при добавлении функционала обновить эти объекты по каждому пользователю? Можно через запрос всем добавить объект со свойством par3 и новый функционал будет добавлен, но тогда все будет заново просматриваться.
twobomb, ничем не лучше, не быстрее и не надежней. Плодить стопятсот строк в этой таблице и для КАЖДОГО посещения страницы их дергать (или дергать кэш) - это полный идиотизм. Это не сущность, джоинить по ней не нужно, выборки делать тоже.
Alex Wells, Идиотизм это json, только в вашем случае не вытягивается нужное нам значение, а мы вытягиваем все возможные значения для КАЖДОГО посещения страницы, кучу данных ради одной булевой, мало того что мы вытянули нам еще пол часа нужно их разбирать и искать нужное нам значение, бред полнейший. А мой способ да если еще и кеш прикрутить милое дело.
P.S. И вообще json'a в реляционных базах данных быть не должно
twobomb, ... вытягиваем.. гребаную строку размером в 100 байт. О да, большая проблема! Как только это можно делать! Конечно же, это сильно хуже, чем каждый раз вытягивать данные ОТДЕЛЬНЫМ ЗАПРОСОМ В ДРУГУЮ ТАБЛИЦУ, особенно учитывая, что нам нужна не "одна булевая", а ВСЕ булевые за раз, потому что этим занимается ФРОНТЭНД, а не мы.
А так да, таблицу создай, форейны прикрути, наполни ее 100500 записями, вытягивай на каждое посещение все записи а потом сверху еще и кэш, что бы кода побольше было.
Зато не прийдется декодить жсон (операция, которая происходит за миллисекунду в данном случае), ага.
Alex Wells, А ну действительно там всего 100байт, там декодить милисекунду, а достать одну булеву этж пол часа нужно ждать! Даже если нужно несколько, зачем доставать и передавать всю таблицу каждый раз! Даже если это нужно на фронтенде, то нужно организовать так чтобы доставалось только нужное или сделать чтобы оно доставалось раз в неделю
twobomb, в смысле только нужное? Зачем так запариватся? В чем, блять, смысл?
И да, достать одну (или несколько булевых) из другой таблицы - занимает СИЛЬНО больше времени и ресурсов, чем JSON поле. Конечно же, все в сравнении, но это же ты тут на спичках экономишь.
Alex Wells, не знаю зачем так запариваться, я изначально предложил вариант быстрый и удобный, и пусть там хоть сто миллиардов записей, мы на спичках не экономим. А еще то что это нужно на фронтенд передавать об этом речи не было, возможно это на пхп обрабатывается
twobomb, ... у нас в проекте так таблица сеттингов была органзована. В итоге отказались нахуй и перешли на JSON. Никаких проблем на довольно большом проекте.
Речь ведь про браузерку? Так храните в куке, какие новинки юзеру уже показаны из появившихся за последние, скажем, три месяца. Просто списком ID в одну строку. Зачем это в базе-то?
Adamos куки можно почистить, зайти с другой машинки + размер их ограничен. в общем куки это что то более просто хранить, к примеру выбранную громкость в плеере. Собъется да и фиг с ней, а вот если чеовек повторно все увидит что уже видел, то это начнет выбешивать.
vovaaar, если человеку что-то навязывают - это выбешивает с первого же раза.
А вот для маркера в углу "вы могли этого не видеть" - более чем приемлемый вариант.
Я конечно могу через запрос всем добавить другой объект со свойством par3 и новый функционал будет добавлен
- не обязательно обновлять, если при получении нет свойства например view_modal у объекта значит просто он считается не просмотренный, при просмотре и подтверждении занесите свойство view_modal=true
Уже делал что-то похожее. Если показывать всегда по порядку, то вовсе не обязательно хранить все со всеми.
Если все новые фичи имеют ID и показываются по порядку, то хранить с каждым пользователем достаточно ID последней просмотренной. И никакого разрастания.
Есть и ограничение, разумеется, показывать можно только по мере возрастания ID, но зато хранить надо намного меньше всего.
