Your point about generating query plans anyway if using dynamic sql is well taken. I can't argue - but see below. > There is some low-hanging fruit here. synt

Your point about generating query plans anyway if using dynamic sql is well taken. I can't argue - but see below. > There is some low-hanging fruit here. syntactically perhaps. But it is bloody expensive to generate new plans. It's quite reasonable for a query to take one or two or even three orders of magnitude more CPU for plan generation than for actually running it. Neither dynamic sql nor parameterisation will deal with that (that I can see). I think we're stuck with expensive repeated query planning. > Most junction tables have essentially identical structure Yes but they are used only to link 2 tables together (I call these join tables because they're just used for joining 2 tables). They aren't used in any other context > This is also pretty common when implementing things like "tags" or "attributes" that apply to more than one kind of object... Maybe. I'd need to sit down with you and talk it over (not happening sadly!) I think parameterised SQL is necessary but also a wide open door to clueless programmers massively increasing the CPU load and I've seen what cluelessness can do to perforemance in an exists-right-now nonparameterised RDBMS. OTOH I've never liked the idea that a tool's power should be reduced to avoid numpties doing damage. You modify the numpty, not the tool.