Compare dates between rows

Question

Hi,
I'm trying to find out how long a record remains in a specific status, based on the following table format:
rec_num, status, date
1, Draft, 10/1/06
1, Submitted, 10/3/06
1, Closed, 10/6/06
2, Draft, 10/5/06
2, Submitted, 10/12/06
2, Closed, 10/16/06
3, Draft, 10/20/06
3, Submitted, 10/28/06,
Each time the status of the record changes, a new row is appended to the table depicting the record number, new status, and date the status changed. However, I only need the timespan between draft and submitted, and between submitted and closed. Records like #3, where a closed date is not available, would need to calculate the difference from sysdate.
So, I'd want the following report:
rec_num, status, date, length in days
1, Draft, 10/1/06, 2 days
1, Submitted, 10/3/06, 3 days
1, Closed, 10/6/06
2, Draft, 10/5/06, 7 days
2, Submitted, 10/12/06, 4 days
2, Closed, 10/16/06
3, Draft, 10/20/06, 7 days
3, Submitted, 10/28/06, 4 days
Is there a way I can do this using Oracle 8i, preferrably simple SQL, like a self join ordered by rec_num, date? If not, PL/SQL? I'm trying to do this without using From/To columns in the table because I would think this is better design. Or is it?
Thanks

Answer 1

WOW! Thanks everyone! This forum is awesome.
I ended up using a combo between both Dima's and Sundar's responses... which were both pretty much the same, except Dima added in for not calculating days on closed records. Here it is:
SELECT rec_num, status, dt,
CASE
WHEN Next_DT IS NOT NULL THEN
Next_DT - dt
WHEN Next_DT IS NULL AND rec_num <> 'Closed' THEN
trunc(SYSDATE) - dt
ELSE
NULL
END as Days
FROM (
SELECT rec_num, status, dt,
LEAD(dt) OVER (
PARTITION BY rec_num
     ORDER BY dt
) AS Next_DT
FROM table_name td
Works great! Now I'm trying to add another column to the report that calculates a running total of days for each rec_num. I can't get it to work. Something like...
SUM(Days)
OVER (PARTITION BY cr_num) "Record Total Days"
Any ideas?
Justin, you're proposed table structure is actually how it is currently designed. But I'm redesigning because I thought it was bad design. There are actually a lot more statuses, and I also keep up with who changed the status (foreign key to users table). So it was like:
rec_num,
title,
description,
status,
draft_by (fk),
draft_date,
submit_by (fk),
submit_date,
approve_by(fk),
approve_date,
close_by (fk),
close_date,
etc, etc, etc
Yeah, it's easier to get what I'm asking for in this forum with that design, and easy use of check constraints to maintain data integrity, but I just didn't feel like it was good design... I'm trying to keep it as normalized as possible. There's like 13 foreign keys to the same users table from this single table! And lots of null values...isn't that bad? Plus, new statuses can be added... and I always thought additions should be added as rows, not new columns?