A few posts prior to mine make the points that I will make regarding database object schemas; but I would like to add that I am actively utilizing these in a rather complex database design and they are extremely helpful. I am a huge fan of database object schemas.

My original intent to utilize database object schemas was to organize the database objects. For example: all of the tables, views and stored procedures that relate to customer information is in a "Customer" schema. All of the tables, views and stored procedures that relate to account information is in an "Account" schema. This has proved to be tremendously helpful when identifying the items that are functionally related.

In the above schemas, I did not apply any special permission combinations. I did however create a couple of schemas where permissions did come into play. I have a schema specifically for sensitive data. With this data being segregated into its own schema, I can better control who can see the sensitive data and who cannot. (I wrote about this in my book "Protecting SQL Server Data")

I also created a schema for all of the objects that are involved with an a batching process. General users cannot see these objects or interact with them. When the time comes and we need to eliminate the batch process, I know exactly what objects were involved. If removal of these objects is the desire it can be with ease and confidence.