Display Complex Hierarchical Data with Server-Side Pagination

Question

Post reply

Display Complex Hierarchical Data with Server-Side Pagination

Peichung Shih

Old Hand

Points: 391
More actions
December 21, 2011 at 9:49 pm

#391186

Comments posted to this topic are about the item Display Complex Hierarchical Data with Server-Side Pagination

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Paul White SSC Guru Points: 150467 More actions · Answer 1

Very nice work, thank you.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

SQLRNNR SSC Guru Points: 281334 More actions · Answer 2

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

george 86905 Mr or Mrs. 500 Points: 551 More actions · Answer 3

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?

Peichung Shih Old Hand Points: 391 More actions · Answer 4

Thanks for your comment. 🙂

SQL Kiwi (12/22/2011)
Very nice work, thank you.

Peichung Shih Old Hand Points: 391 More actions · Answer 5

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.

Peichung Shih Old Hand Points: 391 More actions · Answer 6

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?

george 86905 Mr or Mrs. 500 Points: 551 More actions · Answer 7

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.