Member 13852781 Ответов: 1

Как получить среднее время отклика в SQL


Я пишу, чтобы получить среднее время отклика чата.
например :-

посетитель 2018-02-19 04:32:17
посетитель 2018-02-19 04:32:36
посетитель 2018-02-19 04:32:49
посетитель 2018-02-19 04:38:08
посетитель 2018-02-19 04:38:34
агент 2018-02-19 04:38:37
агент 2018-02-19 04:44:27
посетитель 2018-02-19 04:46:59
агент 2018-02-19 04:50:39
агент 2018-02-19 04:56:28
агент 2018-02-19 04:57:51
агент 2018-02-19 05:00:19
посетитель 2018-02-19 05:01:18
посетитель 2018-02-19 05:01:23

Поэтому мне нужен агент First reply-посетитель first reply для каждого чата
1.2018-02-19 04:38:37-2018-02-19 04:32:17
2.2018-02-19 04:50:39-2018-02-19 04:46:59

Что я уже пробовал:

LEAD(user_type,1) OVER (PARTITION BY chat_id ORDER BY timestamp) as Resp_User,
мин(в случае, когда агент user_type ='', то отметка еще null конец) как agent_time
от (
выберите.chat_id,user_type,метка 'эпохи' + "метка времени" * интервал-1 секунда как "метка времени"
,Функции row_number() над(раздел по.порядок chat_id на "метку"), как РНК
из livechat.chat_events a join livechat.chats ch on ch.chat_id=a.chat_id
присоединяйтесь к livechat.group_info g на g.chat_id=a.chat_id
где g.group_id в (1,4,7)
и.тип сообщения=''
--и приведение(временная метка 'epoch' + ch.started_timestamp * интервал '1 секунда' в качестве даты) между '2018-03-01' и '2018-03-31'
и A.chat_id в ('P4VDURT7MQ')
заказ по метке времени
)где rnk>1
группы 1,2,3
заказ на 3

CHill60

Это не sql - запрос-опубликуйте все остальное

CHill60

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

1 Ответов

Рейтинг:
1

OriginalGriff

Я бы предложил вам немного изменить свою базу данных и добавить "conversationID" к каждой паре коммуникаций: откройте новый идентификатор, когда посетитель начинает, и используйте его для сообщений агента. Если посетитель отвечает после агента, то начинается новый conversationID - я бы использовал для этого значения GUID. (Я бы также добавил идентификатор для каждой "темы" - так что связанные разговоры будут храниться вместе).

Это не только сделает это более точным, учитывая, что SQL Server является многопользовательской системой, и у вас, вероятно, будет несколько агентов, но агент также, вероятно, будет обрабатывать несколько посетителей, поэтому идентификация отдельных разговоров тогда довольно тривиальна: с помощью GROUP BY и получение первой временной метки сообщения для агента и посетителя также довольно просто.

Структура, которая у вас есть, не позволяет ничего из этого, и значительно усложняет обработку данных.