L' Eomot Inversé (1/31/2013)
I wonder why MS has this restriction?
I don't think there will be a real need of chaining computed columns. Whatever experssion may be, we can incorporate in the single column itself.
This is just my assumption.
Tom, Please let me know if there are any real time requiremnt which really need chaining of computed columns, so that I can rectify my assumption.
It's quite clear that T-SQL is Turing Complete except in so far as it can have only finite resources, so there can be no argument that any functionality is missing that prevents certain things from being done - it may make it harder to do them, but it can't make them impossible in principle. If the storage required to do something is more than SQL Server can handle, or the time it would take to do it would be longer that the remaining life of the universe, adding new features to T-SQL won't fix that. If it isn't possible to do something because it is not computable using lambda calculus then Church's thesis suggests that it is impossible to compute it at all, so adding features to T-SQL wouldn't allow T-SQL to do it. Besides, we know how to get the same effect as chaining computed solumns (in at least three different ways - nested views, chained CTEs, repeated expressions, and probably a few more ways).
So many people will say there is no need for such a feature.
From my point of view, those people are wrong. I started in IT doing work on language design, and I learned early on (as does everyone who works in that field) that technical completeness or the ability to do things using complicated constructs or in a way that necessitates having multiple copies of the same source reduces development effectiveness (productivity, quality of delivered product, and cost of maintenance and enhancement). So language design should not exclude a feature that would remove complexity or reduce repetition in source code unless the sonst of the feature would be enough to offset those gains. Chained computed columns would do those things, so the question is whether the added complexity of the T-SQL system (documentation, optimiser, data engine, parser, etc) is great enough to offset the value of the reduced source complexity of things coded in SQL.
Some people will claim that the gains are very small, by producing trivial examples , for example where the most complex expression for a computed value contains a single operator with two arguments and the maximum chaining depth would be two. Real life is unlikely to be like that - the expressions might be quite long and complex, and the chaining depth might be rather higher. To evaluate whether the feature would be worth providing, it would be neccessary to get information from people who would want to use it to find how many had cases where the real complexity/verbosity imposed by the absence of the feature is a significant problem. Until someone carries out such a survey (maybe MS have already done so, I don't know) and publishes the results it's impossible to say whether it would be worth providing the feature.