Recursive Queries in SQL:1999 and SQL Server 2005

  • Comments posted to this topic are about the content posted at

  • Outstanding ! This should be compulsory reading for every 'procedural' minded programmer who thinks 'SELECT orderid FROM customers' is as far as SQL goes ! And don't get me started on 'OO solves data complexity' - Thanks for the article Anthony.

  • May be the most complete article on trees and networks I have ever read (dozens to solve problems with production and bill of materials).
    But also one of the most well written articles in terms of presentation and interest.
    Thanks, it will be a guide for me.
  • This is probably the most worthwhile article I have read on this forum. Does anyone know if this author's books are available in English?

  • Great Article,

    Thanks a bunch to the author.

  • Congratulations for the good Job!



    * Noel

  • Nice article with good examples.


  • Hi, Joe...

    I must say that you are my mentor in SQL. You see in France we have some good professors, but they are not as good as I would like to apply SQL in real life !

    So this article, and some more I will write is dedicated to all those that are involved in good SQL, in wich, I simply think, you are the boss...

    Nice to meet you one day.

  • Unfortunatelly, no books I write are available in English. But I am shure thtat you will find in Joe Celko's book all the matter in the futures release.

  • Very, very nice.  I do a lot with Hierarchies and this will really help when 2005 comes out.  Your examples and text based diagrams are awsome.  Thank you very much for taking the time to do this.  We need to get someone to translate your books to English...

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I apologize in advance if this set of questions takes the topic too far off track.  We can easily take the conversations to a different thread if appropriate.

    Excellent article.  It is very clear that 2005 will greatly simplify traversing hierarchies and networks, at least from a syntax perspective.   

    Most of my work uses multiple orthoganal hierarchies and networks as a way to aggregate and analyze large volumes of data.  For example, consider an organization hierarchy that is related to but not dependent on a geographical network.  Using 2005, what happens to performance as we add this additional real world complexity?

    In data warehouse terminology, the organization tree is a slowly changing dimension.  The geographic tree and the time tree are static.  Data is aggregated and analyzed along the organization tree, along the geographic tree, and along the "time" tree.

    How might one change the examples to walk two or more trees at the same time? For example, suppose one wanted to stop in towns along the way and buy a bottle of wine.  One would need to store the cost of a bottle of wine in each town, for each day, over the last few months.  The "best" route then would consider not only the physical distance, but also the average cost of a bottle of wine over the last two weeks.  This example requires us to walk the geography tree and the time tree at the same time in order to calculate the "best" route.

    In my real work, there are actually nine dimensions of interest.  Three of the dimensions are slowly changing dimensions, two are static dimensions, and four are flat dimensions.  The dimensions are a mix of hierarchies and networks.  Heterogeneous devices submit data on time intervals varying from sub-second to daily.  My current approach is to use recursive algorithms to populate what Kimball refers to as bridge tables, and then associate the aggregate values with nodes in the bridge.  Once collected, the data is stored in the warehouse and available for ad hoc queries for two years.  Yes, there are multiple terabytes of data online for ad hoc query and analysis.

    Given this problem space, how might one modify the examples to efficiently aggregate the data "on demand" rather than storing redundant data for each node in the hierarchies and networks?

    Thanks in advance for any thoughts



  • I am no shure to have well understand your problem. (My english is very far away in my mind...) But I think that valuated the nodes is perhaps not the good solution.

    You can valuate the branches...

    This can be done by adding a weight on the branches of the tree.

    A weight can be constituted as a vector, wich allow as many dimension as you want, but produce a final result in term of "cost".

    Let me give you an example wich is always about roads.

    In france we have very small road call "chemin vicinal" with are close to lane. After we have "route departementale" wich is a step over managing by the department (equivalent of state in US), after we get "route nationale" wich are deliver and manage by the country and over we have "autoroute" wich are speedway.

    The speed is limit as :

    Type of road Km/h Average reduce factor

    Vicinal 50 0,8

    Departementale 90 0,9

    Nationale 90 0,9

    Nationale 4 ways 110 0,95

    Autoroute 130 0,98

    Then we can have some factors that are about where the road is : mountain, or flat land

    Flat : 1

    Small mountains : 0,85

    Heavy mountains : 0,75

    Then we can have some factors that are about the quality of surface of the road :

    Flat : 1

    Small holes : 0,9

    Bad surface : 0,75

    All thoses factors can be specify for all the branches of the tree. Then we can calculate the real travel time, and deduce that a Mac Truck model 125477 will cost 5444$ to go from Paris to Toulouse with 23t of duties

    Is that transposable to your model ?


  • How did I ever miss this one!

    Brilliant. Thanks ever so much.

    Searching the KB articles is like
    picking your nose. You never know
    what you'll find.

  • Merci Frédéric. Et la tristesse, je n'ai que SQL 2000.

    And since your English is much better than my French, I'll just add that I concur with others here. Your article is one of the best I've seen on the subject. Thanks!

  • What can i say.. I think is the best article i have read about using recursive queries in resolving problems. It was exactly what i was looking for. Thanks again for this great article!

Viewing 15 posts - 1 through 15 (of 34 total)

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