Как написать SQL запрос?

Question

[NameOf Var]

Есть база данных MySQL 5.6.36-82.0, в ней хранится таблица историй входа/выхода пользователя в/из зоны. Структура таблицы:
userGUID: VARCHAR(36) - гуид юзера, который зашёл/вышел в зону,
areaGUID: VARCHAR(36) - зона, в которую зашёл/вышел юзер,
inOut: INT(11) - тип действия, 1 - зашёл в зону, 2 - вышел из зоны
timeHappened: DATETIME - время события.

Есть вот такие записи:
-------------------------------------------------------------------------------------------------------------------------------------------
b97c1f20-a5c1-4dd3-99ec-e67625f133c3 | c62f472c-e12d-4201-9eeb-46f67c8854a3 | 1 | 2019-10-01 13:52:12 |
b97c1f20-a5c1-4dd3-99ec-e67625f133c3 | c62f472c-e12d-4201-9eeb-46f67c8854a3 | 2 | 2019-10-01 11:53:20 |
b97c1f20-a5c1-4dd3-99ec-e67625f133c3 | c62f472c-e12d-4201-9eeb-46f67c8854a3 | 1 | 2019-10-01 11:54:31 |
------------------------------------------------------------------------------------------------------------------------------------------

То есть пользователь с гуидом [b97c1f20-a5c1-4dd3-99ec-e67625f133c3] зашёл в зону [c62f472c-e12d-4201-9eeb-46f67c8854a3] в 2019-10-01 13:52:12, затем он вышел из этой зоны в 2019-10-01 11:53:20 и снова зашёл в неё в 2019-10-01 11:54:31 и больше не выходил (т.к. нету ещё одной строчки со значением inOut = 2).

Вопрос. Как одним SQL запросом можно вытащить всех пользователей, которые на данный момент находятся в зонах и ещё из неё не вышли?

Comments

[AUser0]

Hint: если userGUID и areaGUID всегда содержат строку из 36 символов - лучше использовать CHAR(36), длина записи перестаёт быть динамичной, быстрее обработка.

[NameOf Var]

AUser0, спасибо, учту

[ayazer]

а еще лучше использовать binary. он и меньше места занимает, и операции сравнения быстрее.
Да и зачем int для inOut, когда это битовое поле

[NameOf Var]

ayazer, шарповские миграции по дефолту установили для enum'a INT параметр, потом вручную попробую изменить параметр, но спасибо за совет

[ayazer]

NameOf Var, это которые генерирует EF при использовании code-first подхода? они вообще зло

[NameOf Var]

ayazer, хуже. Тут самописные ORM используются

Answer 1

[Руслан .]

Можно так попробовать.
Я тут учитывал кейсы, когда время выхода больше времени входа.

SELECT userGUID, areaGUID, timeHappened AS times
  FROM users in_u
  LEFT JOIN users out_u
         ON out_u.userGUID     = in_u.userGUID
        AND out_u.areaGUID     = in_u.areaGUID
        AND out_u.inOut        = 2
        AND out_u.timeHappened > in_u.timeHappened
 WHERE in_u.inOut  = 1
   AND out_u.inOut IS NULL
ORDER BY userGUID, areaGUID

Answer 2

[Константин Цветков]

Для каждого пользователя определить максимальную по времени запись и отфильтровывать тех у кого inOut = 1.

Answer 3

[Антон Р.]

которые на данный момент находятся в зонах и ещё из неё не вышли?

Чтобы понять что пользователь Вышел счетчик его входов/выходов должен возвращать чётное число, то есть на 1 вход всегда 1 выход = счетчик возвращает минимум 2. Так вот тебе надо посчитать всех юзеров у которых счетчик возвращает нечетное число, вот и всё.

Comments

[Константин Цветков]

Этого мало. Нужно чтобы вышел оттуда, куда зашёл.
И автору вопроса нужно не посчитать, а вывести список.