There are a lot of different ways to structure shaders. One way is to have one or a small set of shaders/effects which have a whole bunch of different capabilities. You turn these capabilities on and off by using #ifdef blocks and setting the appropriate defines when creating the effects. Another option is static branching, where the behavior of the shader is controlled by uniform/shader constant flags that are set before rendering. (This causes the shader to be recompiled a couple times, until the various versions are cached.) You can also use a separate shader for every effect. Then there's fragment linking, which works a lot like C -- you have a bunch of files with different functions, and you link them together to produce a final effect. You can alter the behavior of a shader in fragment linked systems by linking different implementations of the same function in.

The shader-per-effect model is popular with small programs but falls apart quickly as things get bigger. The problem with using an individual shader for each effect is that it leads to a lot of duplicated code. Fragment linking is unpopular because it doesn't mix with D3DX's effects. Some systems will do fragment linking anyway, but at build time instead, so that the final game has a separate shader for every material with lots of duplicated code, but the programmers can work with a more maintainable system. Alternately, you can simulate fragment linking using #include directives and modifying the include handler to use different files (D3DX trick). Static branching, as well as the #ifdef approach, are fairly effective. I find that some combination of static branching and multiple shaders works out best for me.

This page discusses some of the things I mentioned, although you have to scroll down a bit to get past the basics.

Drawback of using many shaders: shader switching overhead. Good number of shaders is 15 - 20 fx files. This number also keeps you shader switching down because of texture, constant changes.