December 21, 2011 at 9:49 pm
Comments posted to this topic are about the item Display Complex Hierarchical Data with Server-Side Pagination
December 22, 2011 at 1:34 am
Very nice work, thank you.
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
December 22, 2011 at 11:04 pm
Nice work thanks. I added this to my briefcase for future reference.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
December 23, 2011 at 9:05 am
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?
December 23, 2011 at 10:22 am
Thanks for your comment. 🙂
SQL Kiwi (12/22/2011)
Very nice work, thank you.
December 23, 2011 at 10:39 am
Thanks for the feedback. I hope this article can be helpful someday.
SQLRNNR (12/22/2011)
Nice work thanks. I added this to my briefcase for future reference.
December 23, 2011 at 11:01 am
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?
December 23, 2011 at 11:20 am
Thanks a lot for the advice. I'll have to digest your idea before I can comment on it, but at first glance, I can say that I will need a flexible solution that allows for an ever-changing groups of Countries and Cities.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply