I've been reading around that nested views can be quite inefficient because:
a) Using views in general involves some overheads (getting info from system tables etc.)
b) The optimiser doesn't do anything intelligent with them but just mixes all the joins from each of the nested views into one big, nasty join
If the only way to get the results I need involves writing this "big, nasty" join anyway, does it matter that I'm not putting it directly into a single view, but breaking it into components so that I can also access parts of the join for other purposes?
If the queries process lots of data, are the system overheads really that noticeable?
you got it, and overhead will be reduced because of that.
example? of what?
I think the example was requested of *me*...
I'm just experimenting now, so don't have a concrete example yet...
Basically, I'm trying to get my principles correct before choosing a method to use. A main concern is code maintainability. Nested views could easily be avoided by repeating code. But building simpler views and then composing them into more complicated ones allows subsequent use of the simpler ones independently whenever they are sufficient.
Functions are precompiled, while views are not. Functions are generally more efficient because of that. In your case, however, some experimentation may be required, because it also means that the entire function must be processed before joining it to your other functions/views/tables. It's possible that if you were using views the server would combine all the view and table references to come up with the most efficient plan for that combination. You would suffer some overhead cost in devising the query plan, but you might avoid needless or redundant joins and calculations that are not required in your final dataset.
If it's not practically useful, then it's practically useless.