Hilfe bei SQL Statement

Mysterox

Lt. Junior Grade
Registriert
Feb. 2005
Beiträge
329
Hallo zusammen,

ich bräuchte mal etwas hilfe bei einem SQL Statement.
Ich habe eine Tabelle in der Ereignisse protokolliert werden.
Die tabelle verfügt über folgende Felder:

Primary_key
Action
TimeStamp
ID

Ich brauche jetzt quasi alle Primarykeys bei denen einbestimmtes Ereigniss aufgetreten ist, nach(zeitlich) denen aber kein anderes bestimmtes Ereigniss eingetreten ist!

In der Tabelle werden An- und Abmeldung protokolliert!
Ich will jetzt quasi sehen wer noch angemeldet ist!

Ist so etwas überhaupt nur mit SQL möglich?

Also mittels schleifen etc. ist das ja kein Problem, aber ich würde lieber soviel wie möglich in einem SQL Statement erledigen, da es sonst so viele Abfragen werden könnten!

THX

Myst
 
Hi Myst,

um deine Frage vernünftig beantworten zu können, musst du noch ein paar Infos bereitstellen.

1. Wenn ich das richtig verstehe, dann wird bei jedem anmelden und abmelden des Users ein neuer Eintrag geeneriert. Somit dürften dir dann immer nur die angezeigt werden, bei denen sich bei der Summenbildung eine Ungerade Zahl bildet oder?
Beispiel:
a. Anmeldung --> ungerade Zahl --> wird angezeigt
b. Anmeldung --> Abmeldung --> gerade Zahl --> wird nicht angezeigt

2. Was passiert, wenn sich ein User anmeldet, sich aber nicht ordnungsgemäß selbst abmeldet. Wird dann vom System ein Eintrag erstellt oder ist der User dann immer online?

Gruß
 
Hi,

also vom prinzip ist das so wie du es sagst!
Wenn ein user sich nicht abmeldet wird er nach mehr maliger prüfung automatisch abgemeldet.

Problem dabei ist nur es können mehrere Anmeldungen pro user statt finden.
Es wird jede anmeldung protokolliert und der user kann sich an mehreren dingen anmelden.
Eindeutig zu indentifizieren wäre dies über die ID

Also ich zerbreche mir jetzt fast den halben tag darüber den kopf und die einzige lösung die ich so schnell habe ist, für jede Option wo der user sich anmelden kann, alle user durch zu gehen, den letzten log ausgeben lassen, wenn es sich dabei nicht ob ein logoff handelt muss es ein login sein und er wäre noch angemeldet!

das problem ist das das x * x Abfragen wären umgenau zusein ca. 9 * 36 Abfragen, was mir persönlich aus performance gründen absolut nicht recht ist!
 
Mysterox schrieb:
...In der Tabelle werden An- und Abmeldung protokolliert!...

Hallo Mysterox,

wenn in der Tabelle tatsächlich nur eine Protokollierung von An- und Abmeldungen stattfindet, solltest Du den Aufbau der Tabelle überdenken. Viel einfacher wäre es, die Anmelde- und die Abmeldezeit als seperate TimeStamps (Spalten) anzulegen, wobei bei der Anmeldung, der Timestamp für die Abmeldung auf NULL gesetzt wird. Dann speicherst Du den Primärschlüssel (ID) in der Session der Anwendung und beim Abmelden wird der Record einfach upgedated.

Somit wäre Deine Abfrage auch sehr einfach mittels dieses Statements zu bewerkstelligen:
Code:
SELECT * FROM ACCESS_LOG WHERE ts_logoff IS NULL;
Diese könnte man dann noch mit einem Schwellenwert erweitern (MYSQL Code).
Code:
SELECT * FROM ACCESS_LOG
WHERE ts_logoff IS NULL
  AND DATE_SUB(NOW(), INTERVAL 30 MINUTE) >= ts_logon;

Wenn dies nicht gehen sollte, z.B. weil Du noch andere Ereignisse in der Tabelle logst, dann musst Du Dir einen brobaten Weg überlegen, wie du die zueinander gehörenden Records finden kannst. Dies wäre z.B. mit einer Referenzspalte, in welcher die PK hinterlegt werden kann möglich. Hier würde dann halt beim Insert der Abmeldung die Referenznummer der zugehörigen Anmeldung hinterlegt werden, und schon kannst du alle Ereignisse vom Typ Anmeldung finden, zu denen es noch keine Abmeldung gibt.

Wenn Du das Tabellendesign nicht ändern willst, gib mal bitte genauere Infos, was die einzelnen Spalten bedeuten.

Ciao
 
Hi,

leider kann ich das Datenbank Design nicht ändern, da es von einer anderen Abteilung leider so vorgegeben ist!

Die Tabelle sieht so aus:
primary_key ==> ist halt ein integer feld als primary key ;-)
agent ==> hier drin steht die Benutzer id
action ==> hier werden alle ereignisse geloggt, leider gibt es ca. 10 ereignisse
info1 ==> hier werden nur weitere informationen zu dem entsprechneden Ereigniss gespeichert
info2 ==> hier werden nur weitere informationen zu dem entsprechneden Ereigniss gespeichert
info3 ==> hier werden nur weitere informationen zu dem entsprechneden Ereigniss gespeichert
timestamp ==> timestamp halt
id ==> die sich auch timestamp und einer fortlaufenden zahl zusammen setzt!
 
Mhhhmmm,

gut über das Tabellendesign müssen wir jetzt nicht reden. Ich finde es eher suboptimal, aber wenn es so vorgegeben ist, kann man da wohl nichts machen. Die Frage ist, steckt die eigentliche Information, die Du haben willst, dort eineindeutig (ja 2 ein) drin. Ich würde fast behaupten, nein. Die einzige Chance näherungsweise an die von Dir benötigten Daten ranzukommen, wäre die Kombination aus agent, action, timestamp. Auch hierbei kann man sich wahrscheinlich nicht wirklich sicher sein, einen korrekten Treffer zu erhalten, sofern die An- und Abmeldeereignisse nicht pro Bereich (Anwendung) eindeutig geschlüsselt sind. Wenn nicht wenigstens dies der Fall ist, hast Du KEINE Chance, eine offene Session korrekt zu identifizieren. In diesem Fall musst Du eben so ehrlich sein, und eine Änderung der Tabelle verlangen, sofern die Anforderung weiter besteht, bzw. eben erläutern, warum die Anforderung im aktuellen Design nicht umsetzbar ist.

Ich wünsche Dir viel Glück, aber ich denke kaum, dass Du an die von Dir benötigten Daten rankommst. Diese Tabelle ist ein klassisches Black Hole, d.h. die Informationen stecken zwar da drin, ich bekomme sie aber nicht sinnhaftig wieder raus. Rede am Besten mit dem verantwortlichen Entwickler, warum er sich zu diesem Ansatz entschlossen hat. Evtl. hat er ja noch einen Schlüssel hinterlegt, den wir jetzt hier nicht sehen können.

Ciao
 
Zurück
Oben