Phil Parkin (10/21/2014)
Eirikur Eiriksson (10/21/2014)
I strongly belief that dynamic SQL solutions should be avoided if possible, it normally doesn't take much of an additional complexity to render them useless or at least very hard to maintain. Only in some very rare and exceptional cases have I had to use dynamic sql for these purposes, usually around xml schema collections or other items of lesser sql purity;-)My suggestion is to accurately define the requirements and the logic, afterwards one can piece together a solution.
😎
Here's[/url] an example. For this case:
Is dynamic SQL avoidance possible? Yes.
Does dynamic SQL perform better than the alternatives? Yes.
So I would say 'use with caution' rather than 'avoid if possible'.
You got a point there!
Think I may have come across this article in the past... not certain though....:hehe:
Handing over the control of logic to "the business" normally saves lots and loads of time, normally justifies a slightly slower execution time.
Purely table driven logic tends to be more robust although somewhat less flexible.
It generally forces a more of an simplification/axiomatization type approach which is clearer and hence more maintainable.
Table driven logic goes hand in hand with a pure set based approach.
😎