不幸的是，术语“模式”已经开始对不同的数据库采用不同的定义。我们正在使用SQL Server 2008 R2，考虑到这一点，我得到了更好的理解，感谢此处的一些其他问题，人们提出类似的问题。但是，在我开始创建数据库之前，我想确保我具备适合我特定情况的权限。
基本上它是公司各部门的数据库。例如，管理员将使用一系列与员工管理相关的表来管理员工。营销将有很多与营销相关的表格。技术支持将有很多技术支持相关的表格。这些“组”可能永远不会互相交互，但它们都是同一个项目的一部分，因此我将它们全部放在一个数据库中，而不是三个独立的数据库中。
我是否理解这意味着我想要三种不同的模式？因此，对于Administration，例如，表将命名为：
Administration.Employees
Administration.VacationDays
Administration.EmployeeAddresses
etc.
然后是技术支持，例如：
Techsupport.Clients
Techsupport.OpenIssues
Techsupport.ClosedIssues
etc.
然后我理解为什么这样做的目的，而不仅仅是让dbo模式中的每个表都用于A）组织目的，以及B）权限目的（具有Techsupport模式访问权限的用户不应该能够例如，访问管理模式）。我想到的想法是，SQL Server定义中的模式是模式就像一个虚拟文件夹，它将相关表组合在一起。
我认为这是正确的，在我读完所有相似的问题之后，但我真的很想确定我走在正确的道路上之前我走得太远并意识到我做错了
是否将所有内容都投入到dbo架构中，并且劝阻一天不打算？您是否应该使用模式，即使对于不一定需要多个模式的小型数据库也是如此？
感谢。
答案 0 :(得分：4)
架构支持两个主要目的：
安全容器。可以在模式上授予权限，并且此类权限适用于模式中的所有对象。例如。 GRANT SELECT ON SCHEMA::Administration TO [foo\bar];授予模式中任何表的SELECT权限，包括将来添加的表。
命名空间。您可以在架构[CptSupermarkt]中部署应用程序，并且知道您的应用与其他应用程序名称冲突的可能性非常低。
流行使用是第一个，因为大多数应用程序不关心与其他应用程序的并行部署，并且通常假定整个数据库的所有权（如果不是整个实例）。但是，有些类型的应用程序（例如，审计工具和监视应用程序）使用模式的命名空间方面（或者，至少大多数应该使用它...）。