Vorweg: Ein Attribut wie eine Attributrolle ("primary key") zu benennen, ist eine *ganz* schlechte Idee. `ID` sollte bereits eindeutig sein, daher ja der Name, und auch dementsprechend den besten Kandidat für den Primärschlüssel darstellen.
Ansonsten: Ja, das geht. Möglicherweise schon mit WHERE, evtl. über HAVING, wenn's sein muss mit Subqueries und Notfalls mit Funktionen, vielleicht auch über einen Self-Join. Was davon möglich ist, hängt wiederum vom verwendeten RDMBS ab.
Mein jüngster Ansatz besteht darin, zunächst den Zeitpunkt der letzten Aktion jedes Benutzers (ich nehme mal an, dass `ID` die Benutzer-ID repräsentiert) zu ermitteln, jeweils für An- und Abmeldung:
|
Quellcode
|
1
2
3
4
5
6
7
8
9
|
SELECT MAX(timestamp) AS last_logon
FROM log
WHERE action = 'logon'
GROUP BY ID;
SELECT MAX(timestamp) AS last_logoff
FROM log
WHERE action = 'logoff'
GROUP BY ID;
|
Da ich die Subquery-Syntax nicht parat habe, folgendes als funktionieren angenommes SQL
, mit dem die beiden Ergebnisse dann verglichen werden:
|
Quellcode
|
1
|
SELECT (last_logon > last_logoff) AS user_is_logged_in;
|
Möglicherweise lassen sich die ersten beiden Queries direkt als Subqueries anstelle der beiden Platzhalter einsetzen.
Sofern die Actions nur An- und Abmeldung darstellen, dürfte bereits dieses klappen:
|
Quellcode
|
1
2
3
4
|
SELECT (action = 'logon') AS user_is_logged_in
FROM log
ORDER BY timestamp
LIMIT 1
|