Database/Table Design Question - Object/Event Model

[orandov]

Hi,

Facts:
I created a database to support an application that tracks events on
different objects. The two main tables are tbl_Object and
tbl_EventLog. Each table has unique ID and on the tbl_EventLog there
is FK for a record in the tbl_Object. The events are inserted all the
time for the same or different objects from the tbl_Object. There are
about 600,000 objects in the tbl_Object and 1,500,000 (and growing)
events in tbl_EventLog.

Question:
The user often wants to know what the last event was for a specific
object.

What is the best way of retrieving the last event?

Should I simply do a max(eventdateti me) on a specific object? or
Should I add a LastEventID column to tbl_Object and update it every
time a new event is inserted? or any other way to implement it?

I chose the second method because I didn't think it made sense search
the event table everytime the user wants to know the last event, but I
wanted to know what the experts thought.

Please let me know what you think.

Thank you,
Oran Levin

[orandov]

Re: Database/Table Design Question - Object/Event Model

Hi --CELKO--,

Thank you for your response. Just to make sure I understand you
correctly, you suggested having 2 datetimes for every event that
occurs. The 2nd one will represent when that event ends and the next
one (which will be a separate record) starts. Therefore, if you want
to know the last event you just look for the event record for that
object that has a null in the end date (or create a view like you
suggested).

That sounds like a good idea.

Oran

[orandov]

Re: Database/Table Design Question - Object/Event Model

Can't find the link on the University of Arizona's website to the book
that works.

This is where I looked...

http://www.cs.arizona.edu/people/rts/tsql2.html

Oran

[--CELKO--]

Re: Database/Table Design Question - Object/Event Model

>Can't find the link on the University of Arizona's website to the book that works. <<

http://www.cs.arizona.edu/~rts/tdbbook.pdf

Developing Time-Oriented Database Applications in SQL, Richard T.
Snodgrass, Morgan Kaufmann Publishers, Inc., San Francisco, July,
1999, 504+xxiii pages, ISBN 1-55860-436-7.

The PDF of this book is here (which looks a little fuzzy but prints
fine, except for pages 30-31, which are here) and its associated CD-
ROM in zip (59MB) or gzipped tar (57MB) formats.

[jhofmeyr@googlemail.com]

Re: Database/Table Design Question - Object/Event Model

Hi Oran,

Celko's response is an excellent example of how to keep history data
in a database, but it may not be valid or correct for your
application.

Can you supply a bit more information about what an "Object" or an
"Event" actually is (DDL and some sample data would help)? The reason
I ask is that an Event is something that happens at a point in time
(or over a period of time). Thus an EventDatetime (and if the event
takes time, an EventDuration/EventEndDatetim e as well) should be
attributes of the Event. Having an open-ended "EndDate" in this case
would be confusing as it implies that the Event is still in progress.
To implement Celko's method correctly, you would need to add 2
datetime columns to your EventLog table; 1 for ValidFromDateti me and 1
for ValidToDatetime . These dates should be independent of the
EventDatetime which presumably stores data about the event (rather
than data about the validity of the row at a point in time).

Finally - the reason why I would like more information is because you
mention nothing about having to do historic data retrieval (i.e. do
you ever need to see a list of events that were the *last ones run* at
some point in the past?) If this "EventLog" table is anything like
any logs that I've worked with in the past, my guess would be no. If
anything, you'll probably be looking for a list of Events that
occurred in a period of time and don't care that the last event on
object "X" was event "Y" that ran 6 months prior to the period you're
interested in. If that is the case you'll simply be looking at the
EventDateTime attribute, not the ValidFromDateti me and adding 2
columns to track validity by datetime seems like overkill to me ...
I'd probably just do a MAX(eventdateti me) or add a bit flag (setting
myself up for slaughter here) that tracks the latest Event for each
Object.

I would still have a filtered view of the data though :)

Good luck!
J

[jhofmeyr@googlemail.com]

Re: Database/Table Design Question - Object/Event Model

Hi Oran,

While Celko's response is an excellent example of how to store history
data, it is not necessarily the best solution for your application...

Could you supply some additional information (DDL, sample data) about
your Object and EventLog tables? Based on the table names and your
description, I would guess that Time (eventdatetime in your original
post, but as events could feasibly have a duration, I would expect to
see an endtime/duration column as well) is actually an attribute of
the "Event" that occurred. This is because Events are things that
occur at a point in time (or over a period of time). To implement
Celko's suggested solution, you would need to add 2 datetime columns -
something like "validfromdatet ime" and "validtodatetim e".

Further - if the EventLog table is anything like the other "log"
tables I've worked with, I would guess that the use of validfrom/to
date ranges is probably overkill. The reason to use date ranges is if
you ever need to answer the question "At this point in history, what
was the last event recorded against each object". My experience is
that usually when looking at log tables, you're more interested in
"What events occurred during this period" questions which would look
at the eventdatetime (i.e. attribute) column, not at the validfrom/to
(audit) columns.

I would probably just use MAX(eventdateti me) or a bit flag (setting
myself up for slaughter here :-/) to indicate the latest event.
Either method will work, my main concern is in highlighting the
difference between attribute information and audit information ...
maybe the eventdatetime column that you allude to *is* actually an
audit column and not an attribute - without a DDL and sample data it
is hard to say :)

I would definitely use a view to facilitate queries of this nature
either way.

Good luck!
J