[quoted text, click to view] >> I can't really change the structure, but I can play with the
indexing. I would still be curious though how other people model this
type of temporal data in a way that makes it easy to work with. <<
Then you're probably dead, because the problem is in the temporal
model. The idea of a time is that it is a contimuum and not a set of
discrete points. This goes back to Zeno, then to Einstein. You can
get some good SQL temporal programming tricks in "Developing
Time-Oriented Database Applications in SQL" by Rick Snodgrass.
The principle is that you need to model events as durations. So we
might re-write your table like this:
[quoted text, click to view] >I can't really change the structure, but I can play with the
indexing. I would still be curious though how other people model this
type of temporal data in a way that makes it easy to work with. <<
Then you're probably dead, because the problem is in the temporal
model. The idea of a time is that it is a contimuum and not a set of
discrete points. This goes back to Zeno, then to Einstein. You can get
some good SQL temporal programming tricks in "Developing Time-Oriented
Database Applications in SQL" by Rick Snodgrass.
The principle is that you need to model events as durations. So we
might re-write your table like this:
[quoted text, click to view] tom_hummel@hotmail.com (Thomas R. Hummel) wrote in message news:<a2c0eeb8.0401140902.723b743e@posting.google.com>...
Hello,
I know that I've seen this question asked on here before, but I can't
find an answer that gives me the performance that I need.
I have a table that stores events for users:
CREATE TABLE Lead_Action_History
(operator_id VARCHAR(20) NOT NULL
REFERENCES Personnel (operator_id)
ON UPDATE CASCADE,
action_start_date DATETIME NOT NULL,
action_finish_date DATETIME, null means ongoing
action_code CHAR(5) NOT NULL, -- needs constraints
CHECK (action_start_date <= action_finish_date)
state CHAR(2) DEFAULT '??' NOT NULL
CHECK (state IN ('Al', 'AK', …)),
PRIMARY KEY (operator_id, action_start_date));
By definition, IDENTITY can never be a key. Your data integrity is
probably a mess because of that design flaw. Why does this table not
have an action code of some kind? The length of a call can be
computed from its start and finish times, so that column is redundant
and subject to errors imprecision.
The join to the LeadMAster table seems redundant since it is just a
list of two letter codes. Why not have a '??' token for the unknown
and avoid NULLs?
[quoted text, click to view] >> I need to write a query that will give me a sum of call_time broken
down by … state <<
That is now very easy:
SELECT state, SUM(DATEDIFF(SS, action_start_date,
COALESCE(action_finish_date, CURRENT_TIMESTAMP))
AS total_time
FROM Lead_Action_History
GROUP BY state;
If you do most of the reports by dates, then use PRIMARY KEY
(action_start_date, operator_id) so the hidden index will be built in
that order. You can also use UNIQUE (action_start_date,