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(eventdatetime) 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

>> I created a database to support an application that tracks events on different objects. The two main tables are tbl_Object [sic: violates ISO-11179 rules and is too vague] and tbl_EventLog [sic: violates ISO-11179 rules].

Pull off that silly "tbl-" prefix and start thinking in sets; in this
case, you should have plural names, unless there actually is only one
"object" and only one "event"

>> Each table has unique ID and on the tbl_EventLog there is FK for a record [sic: rows are not records] 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 [sic] and 1,500,000 (and growing) events in tbl_EventLog. <<

This is the wrong data model. The usual design error is to have only
one time in a row to capture when an event started, then do horrible
self-joins to get the duration
of the status change. Let me use a history table for price changes.
The fact to store is that a price had a duration:

CREATE TABLE PriceHistory
(upc CHAR(13) NOT NULL
REFERENCES Inventory(upc),
start_date DATE NOT NULL,
end_date DATE, -- null means current
CHECK(start_date < end_date),
PRIMARY KEY (upc, start_date),
item_price DECIMAL (12,4) NOT NULL
CHECK (item_price > 0.0000),
etc.);

You actually needs more checks to assure that the start date is at
00:00 and the end dates is at 23:59:59.999.. Hrs. You then use a
BETWEEN predicate to get the appropriate price.

SELECT ..
FROM PriceHistory AS H, Orders AS O
WHERE O.sales_date BETWEEN H.start_date
AND COALESCE (end_date, CURRENT_TIMESTAMP);

It is also a good idea to have a VIEW with the current data:

CREATE VIEW CurrentPrices (..)
AS
SELECT ..
FROM PriceHistory
WHERE end_date IS NULL;

Now, download the Rick Snodgrass book on Temporal Queries in SQL from
the University of Arizona website (it is free). And finally Google up
my article at www.DBAzine.com on transition constraints.

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

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

>> 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.

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 )? 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/EventEndDatetime 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 ValidFromDatetime 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 ValidFromDatetime and adding 2
columns to track validity by datetime seems like overkill to me ...
I'd probably just do a MAX(eventdatetime) 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

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 "validfromdatetime" and "validtodatetime".

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(eventdatetime) 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