You can add a calculated column to your SQL query

SELECT brand, date, weight, datediff(day, '2001/01/01', date) AS daysS
+inceMillemium
  FROM test2 
 ORDER BY brand, date ASC
[download]

And then use [daysSinceMillemium] column to calculate differences in days. Thus you use simple arithmetic instead of Time::Local.

Thanks, unfortunately its more complicated...

The SELECT datediff() is fine for finding ages from a fixed date but not for finding deltas between dates in the same column. Datediff can be used in SQL but then it begins to look like the SQL example and takes ages to run on my 120,000 records with about ~10,000 brands.

I think there is no better way than you have choosen already. All that I can suggest is cosmetic improvements only.

I tried the techniques here:
http://www.onlamp.com/pub/a/onlamp/excerpt/mysqlckbk/index3.html?page=2
it looks like this:


SELECT a.brand,
a.date AS newdate,
b.date AS olddate,  
DATEDIFF(a.date,b.date) AS diff
FROM(
    SELECT brand, date,
        (
              SELECT count(*)
            FROM t_detail_hkjc
            WHERE brand=T.brand
            AND date<T.date
        )+1
    AS rank1
    FROM test
    AS T
    )
AS a INNER JOIN
    (
        SELECT brand, date,
        (
            SELECT count(*)
            FROM t_detail_hkjc
            WHERE brand=T1.brand
            AND date<T1.date
        )
        AS rank2
        FROM test2
        AS T1
    )
AS b ON (a.rank1=b.rank2)
AND (a.brand = b.brand)
ORDER BY a.brand,
a.date DESC
;
[download]

This does work like you suggest by creating the T and T1 alias/copy tables then you line up the sequence numbers (rank1 and rank2) and process the columns of interest.

The problem is it takes about 1 hour to return the query on about 120,000 records... Even merely sequencing the brands alone (the inner Select count(*) part) takes about 7 minutes). I think the SQL is slow because the whole table is searched each time to find the next in sequence. By using my perl program and executing the Select to return the table in the sorted order you know the next record is the one you are looking for. It runs in about 30secs - 1min on the same 120k record table and writes the answer to a new table. Fortunately the data table is only updated about once per week so the query table can be generated immediately after.

When I started out looking to solve this problem I thought it would be a relatively easy piece of SQL to solve a very common problem, e.g. calculate the time between time stamps in a database file for example. But in SQL it seems not;) - I'm no expert in SQL found it tough going. I wish I'd thought of the perl solution earlier!

oopps error in the earlier code I accidentally poseted while not logged in.

I tried the techniques here:
http://www.onlamp.com/pub/a/onlamp/excerpt/mysqlckbk/index3.html?page=2
it looks like this:


SELECT a.brand,
a.date AS newdate,
b.date AS olddate,  
DATEDIFF(a.date,b.date) AS diff
FROM(
    SELECT brand, date,
        (
              SELECT count(*)
            FROM test
            WHERE brand=T.brand
            AND date<T.date
        )+1
    AS rank1
    FROM test
    AS T
    )
AS a INNER JOIN
    (
        SELECT brand, date,
        (
            SELECT count(*)
            FROM test
            WHERE brand=T1.brand
            AND date<T1.date
        )
        AS rank2
        FROM test2
        AS T1
    )
AS b ON (a.rank1=b.rank2)
AND (a.brand = b.brand)
ORDER BY a.brand,
a.date DESC
;
[download]

This does work like you say by creating the T and T1 alias/copy tables then you line up the sequence numbers (rank1 and rank2) and process the columns of interest.

The problem is it takes about 1 hour to return the query on about 120,000 records... Even merely sequencing the brands alone (the inner Select count(*) part) takes about 7 minutes). I think teh SQL is slow because the whole table is searched each time to find the next in sequence. By using my perl program and executing the Select to return the table in the sorted order you know the next record is the one you are looking for. It runs in about 30secs -1min onthe same table.

When I started out looking to solve this problem I thought it would be a relatively easy piece of SQL to solve a very common problem, e.g. calculate the time between time stamps in a log file for example. But in SQL it seems not;)

Add indices to your columns. Also, why do you need the COUNT(*)? Removing that if you don't need it will speed you significantly.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?