This editorial was originally published on 13 Nov 2015. It is being republished as Steve is at the PASS Summit.

One of the things I seem to see more and more is an expanded use of schemas in their development efforts. This isn't something I had done much in the past as almost half of my career was with SQL Server 2000 or earlier, where we didn't really have schemas and we were loathe to tie too many objects to owners. However the last decade has had schemas as a first class citizen in all SQL Server versions since 2005.

I've seen a number of software packages use schemas, but it seemed more as a way of separating out development efforts than any well thought out architecture. However there have been a few interesting uses of schemas as a way of duplicating tables for various uses. ETL and auditing are two of the more common uses, though there have been others.

I ran into an interesting approach recently that I found interesting. A group of developers had added a new schema to separate out their custom objects from all other objects in the database. They did this as the database was created by, and maintained by a third party application. They wanted to create new objects, but wanted them separate from the vendor's objects, and used a new schema.

I thought this was a good idea and wondered who else be doing something similar. This Friday, I wanted to ask the question of the rest of you.

Do you have a custom or reporting schema as a way to separate objects from those that aren't under your development control?

Let us know if you've created some interesting use of schemas. Or are there reasons you don't use schemas? Have you never considered the advantages of using schemas to group  objects in their own section of the database?

I think schemas can be a powerful way of grouping objects, applying separate security, and  organizing your database in a way that makes it easier for developers, and report writers, to manage the complex objects that may clutter up your database.