I'd suggest to maintain data at the leaf-levels of the HIERARCHYID column and create artificial nodes for the roll ups. Let's say the HIERARCHYID column is called LocationId, and all the sales records have their LocationId set to cities. If state roll ups are needed, you can insert 50 artificial nodes into the hierarchy and point sales data's parent to the newly created state nodes; similarly, if country roll ups are needed, add country nodes to the hierarchy and then point state nodes to country nodes. Essentially, you maintain real data at the leaves and build the tree by inserting roll up nodes. I hope this helps. Please let me know if you have any questions. Thanks,
george 86905 (12/23/2011)
Yes, a great post: very useful to know how the paging works. This is great for the single column recursive hierachial data for which it was intended.On the other hand, on a related topic, is there any similiar thinking concerning how to deal with the more general case of non-recursive hierchial data which is found in multiple columns, for example, Country, State, and City, with visibility toggles for State and City.
Unlike the article EmployeeID example, in my case, I don't see a way to predetermine and then set page numbers for the numerous State and City rows and my reports with large recordset do indeed suffer the repaging performance hit described in the article. Any advice?