I have a question regarding the appropriate use of SQL Server database schemas and was hoping that some database gurus might be able to offer some guidance around best practice.Just to give a bit of background, my team has recently shrunk to 2 people and we have just been merged with another 6 person team. My team had set up a SQL Server environment running off a desktop backing up to another desktop (and nightly to the network), whilst the new team has a formal SQL Server environment, running on a dedicated server, with backups and maintenance all handled by a dedicated team. So far it's good news for my team.Now to the query. My team designed all our tables to belong to a 3-letter schema name (e.g. User = USR, General = GEN, Account = ACC) which broadly speaking relate to specific applications, although there is a lot of overlap. My new team has come from an Access background and have implemented their tables within dbo with a 3-letter perfix followed by _tbl so the examples above would be dbo.USR_tblTableName, dbo.GEN_tblTableName and dbo.ACC_tblTableName.Further to this, neither my old team nor my new team has gone live with their SQL Servers yet (we're both coincidentally migrating away from Access environments) and the new team have said they're willing to consider adopting our approach if we can explain how this would be beneficial.We are not anticipating handling table permissions at schema level, as we will be using application-level logins and the 7-character prefixes are not an issue as we're using LINQ so the tables can simply be renamed in the DMBL (although I know that presents some challenges when we update the DBML).So therefore, given that both teams need to be aligned with one another, can anyone offer any convincing arguments either way?
Database Schema Usage
database design;database development;schema
This is far from an authoritative answer on using schemas, but generally you want to use them for one of two reasons:  Security isolation or portability of related objects.SecurityIt's possible to assign security permissions based on schema, which greatly simplifies complicated structures.  Think of an HR system where some people need to see hours, managers need to see files, but only specific individuals need to see anything related to pay.  If you put the pay stuff in a Salary schema you isolate from the rest of the data pretty effectively.This can be done separately with other methods like views or granting permissions to specific objects but if you want to separate a group of related objects this is an easy way to go.PortabilitySome folks believe schemas make objects more portable.  Continuing our previous example, if you need to put the Salary data and related objects into another database or on another server, if they are entirely contained in that schema it would (potentially) be less work to move them all since you script out all objects in that schema.In practice if you stick to a naming convention you can get the same effect without using a schema.So, if you don't have security concerns with these objects, and you don't think you will ever need to move them (and you are going to use a strict naming convention ANYWAYS) then it's really a toss up as to which would be preferred.