sql-server - 数据库架构澄清

Question

不幸的是，术语“模式”对于不同的数据库有不同的定义。我们正在使用 SQL Server 2008 R2，考虑到这一点，由于人们提出类似问题，我有了更好的理解。但是，在开始创建数据库之前，我想确保我的数据库适合我的特定场景。

基本上它是公司各个部门的数据库。例如，Administration 将通过一堆与员工管理相关的表来管理员工。营销方面会有很多营销相关的表格。而技术支持会有很多技术支持相关的表格。这些“组”可能永远不会相互交互，但它们都是同一个项目的一部分，因此我将它们全部放在一个数据库中，而不是三个单独的数据库中。

我的理解是否正确，这意味着我需要三种不同的模式？例如，对于管理，表将被命名为:

Administration.Employees
Administration.VacationDays
Administration.EmployeeAddresses
etc.

然后寻求技术支持，例如:

Techsupport.Clients
Techsupport.OpenIssues
Techsupport.ClosedIssues
etc.

那么我的理解是否正确，这样做的目的不是仅仅将每个表都包含在 dbo 架构中，而是用于 A) 组织目的，以及 B) 权限目的(具有技术支持架构访问权限的用户不应该能够例如，访问管理模式)。我的想法是，SQL Server 定义中的架构就像一个将相关表分组在一起的虚拟文件夹。

在我读过所有类似的问题之后，我认为这是正确的，但我真的想确保我走在正确的道路上，然后再走得太远并意识到我做得完全错误.

将所有内容都扔到 dbo 架构中并取消一天是否不鼓励/无意？即使对于不一定需要多个架构的小型数据库，您是否应该使用架构？

谢谢。

Answer 1

架构支持两个主要目的:

• 安全容器。可以对架构授予权限，并且此类权限适用于架构中的所有对象。例如。 GRANT SELECT ON SCHEMA::Administration TO [foo\bar]; 向架构中的任何表授予 SELECT 权限，包括将来添加的表。

• 命名空间。您可以在架构 [CptSupermarkt] 中部署您的应用程序，并且知道您的应用程序与其他应用程序发生名称冲突的可能性非常低。

普遍使用的是第一个，因为大多数应用程序不关心与其他应用程序的并行部署，并且通常假设整个数据库(如果不是整个实例)的所有权。然而，有些类型的应用程序(例如审计工具和监控应用程序)使用模式的命名空间方面(或者至少大多数应该使用它......)。