考虑一个数据库服务器，它今天的工作是容纳一个数据库。将来可能会将数据库移动到另一个包含多个数据库和模式的数据库实例。
让我们假设应用程序/项目名为 Invoicer 2.0。该数据库称为 AcmeInvoice。该数据库包含所有发票、客户和产品信息。这是演员及其角色和行为的图表。
架构将主要用于轻松地为角色分配权限。这里的额外好处是对象不在dbo 下，并且将来可以将对象和权限移植到另一台机器上。
问题
【问题讨论】：
标签： sql-server sql-server-2005 sql-server-2008 schema naming-conventions
我认为，如果您的架构名称最终与您的数据库架构相同，那么您只是在为您的数据库添加冗余。在您的数据库中查找具有共同范围或目的的对象，并创建一个架构来反映该范围。因此，例如，如果您有一个发票实体，并且您有一些支持发票状态的查找表等，则将它们全部放入发票模式中。
作为一般的经验法则，我会尽量避免使用反映应用程序名称、数据库名称或其他具体/物理事物的名称，因为它们可以更改，并找到一个在概念上代表对象范围的名称将进入架构。
您的评论指出“架构将主要用于轻松地为角色分配权限”。您的图表显示了可以访问某些/所有表或某些/所有存储过程的特定用户类型。我认为试图从概念上将对象组织成模式，并从安全的角度将它们组织成模式是相互矛盾的事情。我赞成在 sql server 中创建角色以反映用户的类型，并授予这些角色访问每个用户类型所需的特定对象的权限，而不是授予角色或用户访问架构以构建您的安全框架。
【讨论】：
我会调用数据库 AcmeInvoice（或其他合适的名称）和架构 Invoicer2。
我的原因如下：Acmeinvoice 意味着我将所有应用程序对象/数据分组在一起。因此，它可以作为一个单元移动到其他机器（备份/恢复或取消附加/附加）。
架构将是 Invoicer2。应用程序发生变化，也许将来您将拥有 Invoicer21（您将创建一个模式），或者可能是一个报告模块或系统（报告模式）。 我发现使用模式可以将一个数据库中的数据/过程分成不同的组，从而更容易管理权限。
【讨论】：
为什么要将架构命名为与数据库相同的名称？这意味着所有数据库对象都属于同一架构。如果是这种情况，为什么还要有模式？
通常，模式用于对共同活动或功能范围内的对象进行分组。例如，根据您所描述的内容，您可能有一个 Invoice 模式、一个 Customer 模式和一个 Product 模式。所有与发票相关的对象都将进入发票模式，所有与客户相关的对象都将进入客户模式，对于产品也是如此。
我们通常也会使用通用模式，其中包括可能对我们的整个应用程序通用的对象。
【讨论】：