I've used schema's since around 1999, when I started using Oracle. The fact that SQL Server didn't use them has always been strange to me and I was pretty happy when they arrived in SQL Server and I even got a nice DBA that let me use them.
When designing the DWH solution architecture, you need to map the physical levels in the database (server, instance, database, schema, table) to the logical layers in your architecture (such as the different layers: staging, persistent storage, data delivery, security management) and having schema's just fills a big gap.
Personally I have used schema's to either map to the logical layers (staging etc.) or more recently to map them to the data delivery sources. I use these straight through all logical layers (mapped to databases) up until persistent storage (or what others might call the DWH layer) and then into the data delivery layer people will get multiple schema's from me:
- one standard one with the "as is" schema (in views with triggers, or if performance is an issue, with semi-materialized views)
- one schema with just synonyms
- one schema with historical views
- other schema's with different ways of looking at the data at will
these are usually separated with postfixes
The advantage is that I can fix things without breaking anything else I don't want to touch. Automated rollout will take care of issues that need to be fixed for everyone.
But as long as people don't dump stuff in [dbo] I'm pretty much okay with anything. My DBA introduced a trigger to prevent people from deploying into [dbo] (or default storage spaces for that matter) and I think that was a pretty good idea.