Why not just dump relational?

> Yes I know relational doesn't do that under the covers, but I'd rather a
> model that explicitly guarantees me instant response than one that 
> guarantees me nothing but typically does pretty well - I've come across 
> enough horror stories about upgrades to the optimisation engine 
> "breaking" carefully crafted code and turning a racehorse into a snail.

Let's just say that the flip side of the optimizer is that you do not have to think about how
to get the data yourself. You declare how the things are related, and using SQL describe what
the result set is, and leave it to the database to work out how to satisfy that query.

It should be clear that this argument requires that we have something more complicated than
"select * from table where id = :x" in mind. As an example, I once wrote a query that produced
a report of top 20 products for all vendors monthly, sorting the vendors alphabetically, the
products by their rank (determined by number of items sold), and also reported the number of
those items sold monthly. The database was a star schema of facts, one row describing an item
x sold at time z, another describing the relationship from item to vendor.

So the optimizer works out which end of the query looks like least work, where a temporary
index might be needed, what rows can be read off purely from index, if any of the subresults
are available in materialized query tables, etc.

To me, it was faster to write the SQL than work out the individual queries and the code in the
host programming language (Perl, in my case) to calculate that same statistic. In principle,
this way is the most efficient as well, as when the database knows what I want, then it is in
the position to do the least work required to satisfy that query.