Она же мультиоператорская. Если операторов, имеющих доступ к перепискам в CRM, несколько (скажем 5-7), то табличка растет ещё быстрее. В теории там должно быть строк больше, чем в crm_message ровно во столько раз, сколько операторов в CRM+1.
Чтобы сделать unread мультиоператорской надо туда сразу всех менеджеров и автора сообщения заносить при появлении нового сообщения, а потом аккуратно выпиливать по одному. Тогда она и будет стремиться к нулю в идеале.
Допустим появился в CRM новый менеджер с правами на доступ к сообщениям. Его получается надо занести сразу во все сообщения и старые в том числе или только в те, которые после "рождения" нового менеджера появились? Этот момент получается самый тонкий.
Мне кажется у WA слегка помутнее от такой предложенной логики, хотя она по-своему хороша и даже изящна т.к. приостанавливает рост таблицы в зародыше при той же информативности бекенда. Они в данном случае решают задачу в лоб тупым наполнением таблицы базы.
Всё так. И можно было б жить, но где-то глубоко внутри немного напрягает то, что текущая таблица не поддается чистке. Совсем не поддаётся.
Если какую-нить таблицу с логами, историей, еще чем-нибудь можно просто обнулить без каких-либо серьезных последствий, то эту придется таскать за собой до скончания сервера.
Добавление новых комментариев к этой теме отключено.
Мы используем куки, потому что без них сайт не смог бы нормально работать.
2 комментария
Она же мультиоператорская. Если операторов, имеющих доступ к перепискам в CRM, несколько (скажем 5-7), то табличка растет ещё быстрее. В теории там должно быть строк больше, чем в crm_message ровно во столько раз, сколько операторов в CRM+1.
Чтобы сделать unread мультиоператорской надо туда сразу всех менеджеров и автора сообщения заносить при появлении нового сообщения, а потом аккуратно выпиливать по одному. Тогда она и будет стремиться к нулю в идеале.
Допустим появился в CRM новый менеджер с правами на доступ к сообщениям. Его получается надо занести сразу во все сообщения и старые в том числе или только в те, которые после "рождения" нового менеджера появились? Этот момент получается самый тонкий.
Мне кажется у WA слегка помутнее от такой предложенной логики, хотя она по-своему хороша и даже изящна т.к. приостанавливает рост таблицы в зародыше при той же информативности бекенда. Они в данном случае решают задачу в лоб тупым наполнением таблицы базы.
Всё так. И можно было б жить, но где-то глубоко внутри немного напрягает то, что текущая таблица не поддается чистке. Совсем не поддаётся.
Если какую-нить таблицу с логами, историей, еще чем-нибудь можно просто обнулить без каких-либо серьезных последствий, то эту придется таскать за собой до скончания сервера.