![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
| With Member [Measures].[SalesRank] as |
#3
| |||
| |||
|
|
Not sure if I understand exactly what your query results should look like, but here's an MDX ranking example from Foodmart (adapted from my earlier post). It lists stores at the country level along rows (you could replace with a set of servers). On the columns are cross-joined months of [1997] with the Unit Sales and Store Rank (by Unit Sales): With Member [Measures].[SalesRank] as 'Rank([Store].CurrentMember, Order(StrToSet("Axis(1)"), [Measures].[Unit Sales], BDESC))' Select CrossJoin(Descendants([Time].[1997],[Time].[Month]), {[Measures].[Unit Sales], [Measures].[SalesRank]}) on columns, [Store].[All Stores].[USA].Children on rows from Sales - Deepak *** Sent via Developersdex http://www.developersdex.com *** Don't just participate in USENET...get rewarded for it! |
#4
| |||
| |||
|
#5
| |||
| |||
|
|
Hi John, Performance is definitely a problem when you're ordering 300K+ members on the fly - I don't have a good answer offhand, but maybe others in the group have some ideas? Some initial questions/thoughts are: - The data is probably not sparse, ie. most servers would have data on any given day. Otherwise, excluding the empty server members first might have helped. - Does the fact table have a single daily row per server? - What does the Server hierarchy look like; and are there some branches/subtrees that are highly unlikely to contain the top servers on any given day (for example, by class or model of server)? If so, maybe a MaxBytes measure could be used to eliminate many subtrees prior to ordering - any node with MaxBytes < Min(TopServers) could be ignored. - Deepak *** Sent via Developersdex http://www.developersdex.com *** Don't just participate in USENET...get rewarded for it! |
#6
| |||
| |||
|
![]() |
| Thread Tools | |
| Display Modes | |
| |