1/24
does indeed convert to 1 hour in this context. Personally, I prefer using interval notation rather than adding and removing fractional days.
SYSDATE - interval '23' hour
seems much more readable to me.
Your materialized view is updated every 24 hours. It will be updated every day at 1am.
TRUNC(SYSDATE+1) + 1/24
returns tomorrow at 1am. trunc(sysdate)
is midnight today, trunc(sysdate+1)
is midnight tomorrow, and trunc(sysdate+1) + 1/24
is tomorrow at 1am.
If you are querying the view between midnight and whenever the materialized view finishes refreshing (presumably some time after 1am), there may be rows that are more than 23 hours old that are not yet reflected in the materialized view. Depending on the architecture (and the reason that entries apparently exist in two different objects), I'd be more concerned about duplicate rows. At 8am, for example, the materialized view will have data that is only 7 hours old (presumably), which could also be returned from my_view_b
(I assume that when you say "constraint" you really mean that there is a predicate on my_view_b
like WHERE MY_DATE > (SYSDATE - 1) + 1 / 24
).
Taking a step back, though, the approach seems dubious to me. Having detail level data in a materialized view and in a separate table that is accessed via a view and then going to the expense of doing a UNION
to remove duplicates seems highly dubious to me. Materialized views will often improve performance if you are using them to pre-aggregate data or at least to pre-compute something that is costly to compute at runtime. That doesn't appear to be what you're using them for, though, so I'm rather dubious that this is doing anything other than causing you to use more disk space, put more pressure on the buffer cache, and suffer worse performance.