From: "Keith Gray" <keith@heart.com.au>
> Richard Huxton wrote:
> >
> > Indexes on underlying tables should be used though. Difficult to suggest
> > what indices you might need without knowing the view/tables/queries
> > involved.
>
> As an example I may have an "Invoice" table with several thousand
invoices.
> I could design a query/view "Aged" to get all unpaid invoices
> greater than 15 days old.
>
> I would often look for Invoices per Client and should have an index on
> Invoice(ClientID).
>
> e.g. CREATE INDEX Invoice_ClientID ON Invoice(ClientID);
OK - makes sense.
>
> Is there any advantage in having an index on ClientID for the Aged query?
>
> e.g. CREATE INDEX Aged_ClientID ON Aged(ClientID);
>
> Would this index be continually maintained by the RDBMS or only on lookup?
You can't do this at all I'm afraid. You can only index actual data. In this
case you already have an index on clientID so you're covered.
For your 15-day query, if it looks something like:
SELECT * FROM invoices WHERE status='UNPAID' AND inv_date < CURRENT_DATE-'15
days'
you might want indexes on inv_date and status.
This doesn't mean that they will definitely be used though - it depends on
how many records you have and how many the query returns.
It *is* possible to define an index on a function, so you could in theory
write a quite_old(inv_date) function and index that, but I doubt it makes
much sense in your case.
- Richard Huxton