SQL Server：命名模式的约定

Question

考虑一个数据库服务器，其今天的工作是容纳一个数据库。可能数据库将在未来移动到另一个数据库实例，该实例包含多个数据库模式。

让我们假装应用/项目称为Invoicer 2.0。数据库被称为AcmeInvoice。数据库包含所有发票，客户和产品信息。以下是演员及其角色和行为的图表。

的模式（一个或多个）将在很大程度上被用来很容易地将权限分配给角色。这里额外的好处是对象不在dbo之下，而且对象&权限可以在将来移植到另一台机器上。

问题

• 你当命名架构使用什么约定？
• 将模式命名为与数据库相同的名称是否很好？

Answer 1

我认为如果您的模式名称最终与您的数据库模式相同，那么您只是为您的数据库添加冗余。在数据库中查找具有共同范围或目的的对象，并创建一个模式来反映该范围。因此，例如，如果您有一个发票实体，并且您有一些支持发票状态的查询表等，则将它们全部放入发票模式中。

作为一般的经验法则，我会尽量避免使用反映应用程序名称，数据库名称或其他具体/物理事物的名称，因为它们可以更改，并找到一个概念上代表对象范围的名称这将进入模式。

您的评论指出“模式将主要用于轻松分配角色权限”。您的图表显示了可以访问某些/所有表格或某些/所有存储的特效的特定用户类型。我认为试图在概念上将对象组织到模式中并从安全角度将它们组织到模式中是相互冲突的事情。我赞成在sql server中创建角色以反映用户的类型，并授予这些角色访问每个用户类型所需的特定对象的权限，以便授予角色或用户访问模式以构建安全框架。

Answer 2

为什么要将模式命名为与数据库相同？这意味着所有的数据库对象都属于同一个模式。如果是这样的话，为什么要有一个架构呢？

典型的模式是用来在活动或功能的共同范围内对对象进行分组。例如，根据您所描述的内容，您可能具有发票模式，客户模式和产品模式。所有与发票相关的对象都将进入发票模式，所有与客户相关的对象都将进入客户模式，而产品则相同。

我们经常会使用Common架构，其中包含可能对我们整个应用程序通用的对象。

Answer 3

我会调用数据库AcmeInvoice（或其他合适的名称）和架构Invoicer2。

我的理由如下：Acmeinvoice意味着我将所有的应用程序对象/数据分组在一起。因此它可以作为一个单元移动到其他机器上（备份/恢复或未连接/附加）。

该模式将是Invoicer2。应用程序发生变化，将来可能会有Invoicer21（您将创建一个模式）或者报告模块或系统（Reports模式）。 我发现模式的使用允许我将一个数据库中的数据/过程分成不同的组，这使得管理员权限变得更容易。