>Thanks Keith. If I understand you correctly, I create one view for each combinaison of joins possible and don't filter the data in the view. I will filter the data in the business layer. That's what you mean?
>

Yes, you've got the gist of it - except that you will not be filtering the data in the business layer, but passing dynamic SQL that queries the view, not the base tables.

>What is the difference between a stored procedure that return a table and a view?
>

Not a view, but an indexed view (or a materialized view). They are two different animals. An indexed view is like a poor-man's analysis cube. You are flattening the normalized tables to make queries run much faster. You will be bypassing the joins and 80% of the work that the optimizer performs when generating an execution plan. The whole query will be one or more index scans.

The downside is that you have to maintain a set of configuration options in the database or individually on any object that interacts with the view. And the index(es) will eat up a lot of disk space.

If your database isn't already configured with these options, it could be a lot of work to perform an impact assessment of the changes.