Should I use user schema seperation in SQL Server

User Schema

Introduction

Prior to SQL Server 2005, a database object  is owned by a user. That user could be DBO or any valid user account. That table is now directly linked to that user– the user cannot be deleted without removing the table or changing the owner of the table. The table can only ever be owned by one user. User-schema separation, introduced in SQL Server 2005, means that the table is no longer owned by any user; it belongs to a schema. In turn, the schema is owned by a user.

A schema is separate entity within the database. It is created by using the CREATE SCHEMA statement. A schema can be owned by a user, a role, or a group. A user executing CREATE SCHEMA can be the owner of the schema or it can allocate another user as the schema owner with appropriate IMPERSONATE permissions. A schema only has one owner, but a user can own many schema. Schema ownership is transferable.

Pros

1. Schema allows much more control of access, and levels of access for the administrator
2. Ownership of schema and the database objects within them is transferable
3. Objects can be moved between schema
4. Multiple database users can share a single schema
5. A database user can be dropped without dropping objects in a corresponding schema
6. Schema logically separates objects in a database. 

Cons

1. If not used wisely, (considering dependencies and commonality of objects), user schema can be quiet confusing.
2. Schema organization must be considered during the design phase to avoid problems with the code. Changing schema design late in the fame could cause many changes in the code.
3. For Programmers who use C# code, although, in most of the cases, user schema works like Namespaces in C#, note that the notations like HR.People schema will be converted to HR_People class in C#.