Sql MAX DateTime and if clause? - sql-server

Question

My 2nd Sql question on SO today - I need to brush up my Sql skills!!!!
I have the following three tables....
Diary, Entry, and EntryType
A Diary can have many Entry(ies), each Entry is of a particular EntryType.
Entry has a created DateTime
EntryType has an Id, and SomeOtherValue (int)
EDIT
Sorry Chaps. Thanks for response so far but I didn't explain it well enough; the requirements have changed a bit.....
I would like the Id of any Diary where its latest Entry that is greater than #lastDateTime AND EntryType.someOthervalue != 0 has a EntryType.someOthervalue == #someValue
Or to put it another way....For all those Entry rows with a created Date time > #lastDateTime, ignore the someOtherValues that equal 0, and if the top 1 left over has a someOtherValue = #someValue, return the Id of the diary!!!!
Does that make sense??? I'm not sure what I should be putting my MAX, WHERE, and HAVING (if anything at all!)
Thanks,
ETFairfax.

Answer 1

If you want the last entry, and then with the last entry, test whether the entrytype of that last entry is #somevalue, then this should be the right query
select diaryid
from (
select rn=row_number() over (partition by e.diaryid order by e.created desc),
d.diaryid, et.someothervalue
from entry e
inner join entrytype et on e.entrytype = et.id
where e.created > #lastDateTime
) X
where rn=1
and SomeOtherValue = #someValue -- of the last record
If however, you mean, among the entry types of #somevalue, is the latest one >#lastDateTime, then it is
select e.diaryid
from entry e
inner join entrytype et on e.entrytype = et.id
where et.SomeOtherValue = #someValue
group by e.diaryid
having max(e.created) > #lastDateTime
Note: For a db with proper references, the diary_id can be derived from entry without going back to diary. The only reason for linking back to diary is if you need the full diary record, or if there is no foreign key and you need to validate that the diary_id exists.
For the 2nd type, there is another way to write this that is still ANSI compliant and may be faster. This works by deducing that for the MAX e.created to be greater than #lastdatetime, ANY record
EDIT: As Andriy points out for the 2nd query (directly preceeding this statement), the HAVING clause can be moved to the WHERE clause based on the same fact, but I have left the query in that form to match the expression of the requirements (not using the deduced simplification).
select e.diaryid
from entry e
where exists (
select *
from entrytype et
where e.entrytype = et.id
and et.SomeOtherValue = #someValue)
and e.created > #lastDateTime
GROUP BY e.diaryid
This EXISTential test can stop inspecting entrytypes for an entry as soon as it finds one matching somevalue and created instead of fully processing the join and aggregating (max) before filtering it down in the HAVING clause.

Answer 2

How about something like this:
select d.diary_id
from diary d
join entry e on(d.diary_id = e.diary_id)
join entry_type et on(e.entry_type_id = et.entry_type_id)
where et.someOthervalue = #someValue
group by d.diary_id
having max(e.created) > #lastDateTime;

Answer 3

Another approach if you are using SQL Server 2005+
With EntryDates As
(
Select E.DiaryId
, Max(E.Created) Over ( Partition By E.DiaryId ) As LastCreateDate
From Entry As E
Join EntryType As ET
On ET.Id = E.EntryTypeId
Where ET.SomeOtherValue = #SomeValue
)
Select DiaryId
From EntryDates
Where LastCreateDate > #lastDateTime
Group By DiaryId

Answer 4

Diary, Entry, and EntryType
SELECT
FROM
Diary D
CROSS APPLY (
SELECT TOP 1 E.EntryID
FROM
Entry E
WHERE
D.DiaryID = E.DiaryID
AND E.CreatedDatetime > #LastDateTime
AND EXISTS (
SELECT 1 FROM EntryType ET
WHERE E.EntryTypeID = ET.EntryTypeID
AND ET.SomeOtherValue <> 0 -- or = #SomeValue ?
)
ORDER BY CreatedDatetime DESC
)
An index in Entry on CreatedDatetime would be helpful, but either the table's clustered index should have DiaryID or the index should contain it as one of the indexed columns.
I presume the EntryTypeID table is small compared to the others, so it's most likely going to be a table scan anyway, so indexes won't help much. If your execution plan gets some high number of reads on the EntryType table, please let me know and we'll try to fix it. I'm hoping the engine is smart enough to realize this table is small and only hits it up once, and puts it on the left side of a LOOP join somewhere.
Please let me know how this goes and if it's not working right I'll tweak it. I'm sure we can get a really nicely-performing query going.