Display Complex Hierarchical Data with Server-Side Pagination

  • Peichung Shih

    Old Hand

    Points: 391

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

  • Paul White

    SSC Guru

    Points: 150442

    Very nice work, thank you.

  • SQLRNNR

    SSC Guru

    Points: 281210

    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

    SSC-Addicted

    Points: 441

    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

    Thanks for your comment. 🙂

    SQL Kiwi (12/22/2011)


    Very nice work, thank you.

  • Peichung Shih

    Old Hand

    Points: 391

    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

    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

    SSC-Addicted

    Points: 441

    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 8 (of 8 total)

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