sql-server - SQL Server : conventions for naming a schema

Question

考虑一台数据库服务器，其当前的工作是容纳一个数据库。该数据库将来可能会移动到另一个包含多个数据库和架构的数据库实例。

假设该应用程序/项目名为 Invoicer 2.0。该数据库称为 AcmeInvoice。该数据库保存所有发票、客户和产品信息。这是 Actor 及其角色和行为的图表。

架构将主要用于轻松地为角色分配权限。这里的额外好处是对象不在 dbo 下，并且对象和权限将来可以移植到另一台计算机。

问题

• 在命名架构时使用什么约定？
• 将架构命名为与数据库相同的名称是否合适？

Answer 1

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

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

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