I already wrote some notes on choosing dimension for publish in this post.

Today I just want to add some of points:

• If you’re up to publishing some serious amount of data, variant with adding a dummy dlist with 1 item and using it as dimension for publish seems a very bad idea.  You’re terribly slowing proccessing and wasting tablespace. So you have to choose a dimension for publish to reduce table size and speed things up
• Dimension for publish must be: ** Stable. It shouldn’t change or change very rarely, since these changes will cause Framework Manager models \ ETL models changes. ** Have sane (~3-33) number of elements. If less than 3, there’s no win in performance. If more than 30, ensure it won’t change, because big dimensions change more often than small ones.
• There are dlists that are naturally stable aka measures, like {Quantity;Price;Sales}
• In other cases timescale seems a really good choice. For example, if months dimension doesn’t have year signs in name (like Jan, Feb, Mar), columns in publish won’t change ever.  To work with timescale published data you can use sql unpivot queries, that will virtually turn it into view publish, but it’ll way more effective than publishing it by 1elem dimension in first place. I’ve settled for this variant in my current project. Moreover, if you wrap this unpivot sql into ETL procedure, you can treat all published data uniformly while loading into datamarts (publish all needed cubes on timescale, use the same etl procedure).