Как правильно оформить SQL запрос для аналитики в каналах?
Проектирую бота в функционал, которого входит статистика по обращениям в каналах филиала и отправка сообщений работников в канал в зависимости от выбранного филиала регистрации. Структура базы данных:
Таблица "Users": id, user_id (Telegram ID пользователя), user_name (first_name в телеграм),user_surname (second name в телеграм), MRF (филиал, который пользователь выбирает при первой регистрации) Таблица "For Posts": id, username (first name + last name пользователя), user_id (айди пользователя), created_at (время создания поста по UNIX TIME), text (текст сообщения, если был), message (message.id в канале), chanel_id (айди канала куда отправилось обращение) Таблица "For Reply":id, username (firstname +last name пользователя), user_id (айди пользователя), reated_at (время создания поста по UNIX TIME), text (текст сообщения, если был), reply to id (message.id сообщения в канале в котором пишется комментарий), message (message.id комментария на пост), chanel_id (айди канала куда отправилось обращение). Словари:
managers (занесены user id диспетчеров и их ФИО для отображения их в отчетах),
channels (channel_id каналов для обращений и их название). Виды аналитики:
Общая (обращения по всем каналам)
По сотрудникам (статистика отработки обращений по ФИО сотрудников во всех каналах)
По каналам (статистика отработки обращений сотрудниками по каждому каналу)
По выбранному каналу (статистика отработки обращений сотрудниками по каждому каналу) Как считается статистика:
Интервал: дата статистики которая необходима пользователю
ФИО: ФИО сотрудника отрабатывающего обращение
Всего сообщений: обращения взятые в работу до 30 секунд + после 30 секунд
До 30 секунд: обращения где диспетчер ответил в комментариях к посту ДО 30 секунд
После 30 секунд: обращения где диспетчер ответил в комментариях к посту ПОСЛЕ 30 секунд
SL % (Service level): Доля обращений взятых в работу до 30 секунд Проблемы:
1)Сообщения по кол-ву верно считаются в статистики по КАНАЛАМ, но при этом ВСЕобращения засчитываются как до 30 секунд.
2) В отчете по сотрудникам считаются не все обращения за выбранный период, а только половину и них. В БД message.id постов часто пересекаются с другими каналами (всего каналов 8), насколько я понял разработчики не сделали их индивидуальными как user_id или chanel_id.
3) Поможет ли вайп БД Sqlite? БД формируется уже 2 месяца, возможно Message.id в разных канал пересекаются из-за этого (в функции сохранения ответа на тикет есть условия, которое дает сохранять ток первый ответ диспетчера (учитывается как обращение которое взяли в работу).
Возможно, у кого-то был опыт с решением подобных кейсов, код отвечающий за аналитику в комментариях ниже.
Алан ГибизовDr. Bacon, , срабатывает ограничение по символам (лимит до 10 тысяч символов) в этой связи поместил в комментариях, возможно у Вас есть какой-либо вариант выхода из положения? буду благодарен. В коментариях добавил спойлер
Алан Гибизов, я сократил до того что относится к теме моего вопроса, а именно код формирования отчетов по которым вопросы (их на самом деле больше) и каким образом сохраняются в БД посты и ответы на них. Полный исходный код длинною 1800 строчек, поэтому изначально пытался сократить его по максимуму.
Алан Гибизов, по пунктам:
1) Значит ошибка в вычислениях. Судя по описанию время ответа = reated_at - created_at.
2) По логике ключевыми полями должны быть id и channel_id, тогда дублирующиеся id у сообщений не будут проблемой
3) Не поможет, если не разобраться что не так у вас сохраняется.
Код подробно не смотрел. На мой взгляд сами записи в таблицу пишутся неверно в save_engineer_reply_info
в WHERE учитывается только id сообщения и игнорируется канал, из-за чего скорее всего дальше по коду не срабатывает INSERT и не все записи пишутся.
Стоит еще раз посмотреть на БД, судя по проблемам у вас там возможно даже нет ключевых полей или они неверно определены иначе проблема дубликатов не должна была возникнуть.
Поправить связь таблиц, убедиться что каждая запись однозначно определяет обращение или ответ, по возможности написать миграцию и перенести часть не дублирующихся данных из старой базы в новую и уже на новой делать аналитику.