A lot of the time this query needed was due to the sheer volume of data. It seemed to me that restricting the tables as much as possible before the joins produced the quickest results. I cannot be sure as I was also changing other things so I maybe completely wrong. It would really depend on the order in which the lines of the query actually get executed and also on which is more efficient, a join or a restrict. I think it would be restrict. I believe there is a specific piece of software/part of the DB that decides how the query is executed. I cannot remember off the top of my head, I am guessing it is called something like Query Optimizer, lol.
SQL wise, I do not have the code here but I did something like this:
Code:
SELECT
user_num
location_ref,
MVD_table.MVD,
[...other entities I am interested in]
FROM
[other tables]
( SELECT
location_ref,
MAX(visit_date) AS MVD
FROM
visits
WHERE
[restrict visits to only relevant visits]
HAVING
date < 30-SEP-04 ) MVD_table
WHERE
[various other restricts and joins]
ORDER BY
user_num, place_ref
What I was trying to do slightly changed. I wanted places that had not been visited since September 30th, although the code is only slightly changed. HAVING allows you to restrict an entity when it has had a function such as MAX() used on it.
I also found that an SQL statement can be put in parenthesis and given a table name and thus accessed like a table. It is necessary give MAX(visit_date) a reference name using "AS" so it can be used else where. My understanding of why this is superior is that the last_visit dates are all found once, as opposed to accessing the tables on each run through.
I am unsure if I could have got away with using MAX(visit_date) AS without the extra select statement MVD_table. At any rate I had to draw a line under it time wise as I believe my code to be alright. I am interested to hear comments on this solution?
GAteKeeper, I did find that everything in a SELECT statement had to be in a GROUP BY clause unless it was included in an aggregate function, e.g. MAX(). It was hard to get my head around exactly what the effects of including so many items in the GROUP BY clause might be.