[Mondrian] A couple of "best practices" questions

[Julian Hyde]

> Eric:
>
> My sense is that the index hint probably is useful at least on some  
> databases, though obviously the above 3 don't qualify as an 
> exhaustive  
> list.  Given the way MySQL and SQL Server seem to work, I'm not sure  
> tagging on arbitrary text would work.  At the very least, we'd need  
> some kind of syntax indicating where those tags need to go, at which  
> point we may just be better off declaring an attribute and 
> handling it  
> in the dialects.

Your 'forceIndex' attribute is too narrowly focused on one area of hints in
queries. I know people will want to use other kinds of hints. I suggest a
<Hint> sub-element, with 'type' attribute and text content. It's up to the
dialect to know how to interpret that type of hint.

Therefore:

    <Dimension foreignKey="my_dim_id" name="foo">
	<Hierarchy hasAll="true" allMemberName="All foo"  
primaryKey="my_dim_id" >
                 <Table name="my_dim" alias="my_dim">
                     <Hint type="force_index">my_index</Hint>
                 </Table>
		...
	</Hierarchy>
    </Dimension>


I also worry about what will happen if mondrian identifies shared usages of
the same table internally. It will tend to generate hints wherever the table
is used. Nothing we can do about this, but it might bemuse some folks.

> > Julian:
> >
> > why not extend the syntax of the Order function, e.g.
> >
> > Order(
> >  [Customer].Members,
> >  [Measures].[Unit Sales] ASC NULLS COLLATE AS ZERO EMPTY COLLATES  
> > LAST)
> 
> I can't explain why the original authors did it this way, but as for  
> why I didn't think of it?  It was probably just too flippin' 
> obvious. :)

It's obvious to anyone who has read the SQL standard. All 10 of them. 6 of
these are dead, and most of the others are wishing they hadn't.

Julian