Jeff Moden (2/27/2013)
dwain.c (2/27/2013)
However I think it may be a bit overkill in this case where all you need to do is sum the children of a parent to one level deep (assuming this is right).If that's all they'll EVER want to do, then I agree. While it’s true that I tend to “over” plan by making such "simple" things bullet proof to scope changes, scale changes, and future requirements, let's hope that the complexity of the doubly-linked (each row has the parent and child listed) hierarchical Adjacency List in T1 isn't the foreboding of more complex requests that I think it will be.
The thought did occur to me that maintaining those child nodes in the relations table was probably going to incur some overhead (and headaches).
But I also figured that you need to learn to crawl before you can learn to run.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St