[Mondrian] A couple of "best practices" questions

Eric McDermid mcdermid at stonecreek.com
Fri Jun 19 13:32:21 EDT 2009

A couple more tidbits from my porting work...

1) Forcing table indexes

For performance reasons, the code I'm porting includes a new attribute  
on the Table schema element: forcedIndex.  If set, it forces SqlQuery/ 
SqlTupleReader to use the named index when reading from the table.

Is this an enhancement that sounds appropriate to add in to the  
Mondrian mainline, or is there a better way to go about this using  
existing Mondrian capabilities?  If the former I'm happy to write some  
tests abd contribute it; if the latter I'd like to make sure we're  
doing it the right way instead.

2) Sparsely populated fact tables and sorting

One property of the datasets we're working with is that some of the  
dimension tables can be large (up to a million rows or so), but the  
fact tables tend to be much smaller and relatively sparse, meaning  
that in many cases there are no rows in the fact table that associate  
with a given dimension.

That in and of itself is fine, but in terms of business behavior we  
know that if there is no associated row in the fact table, it's  
equivalent to having a row full of zeros.  We'd like to see that  
knowledge carry through to sorting results, etcetera (i.e., if the  
value is nonexistent, sort it as if it were zero instead).

This is currently implemented by overriding the sort functions to  
treat null/empty as zero, which frankly makes all involved a little  
itchy.  Is there a better approach to this problem?

  -- Eric

More information about the Mondrian mailing list