数据库架构说明

Posted 2023-03-23

【中文标题】数据库架构说明

【英文标题】：Database schema clarification

【发布时间】：2012-01-23 03:16:09

【问题描述】：

不幸的是，“模式”一词对不同的数据库有不同的定义。我们使用的是 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 架构中并呼吁一天不鼓励/不打算？您是否应该使用架构，即使对于不一定需要多个架构的小型数据库也是如此？

谢谢。

【问题讨论】：

相关：msdn.microsoft.com/en-us/library/ms190387.aspx 和 blog.sqlauthority.com/2009/09/07/…

是的，谢谢，这些资源非常好，我先阅读它们。我只是想抛出我的具体情况并得到确认。太多次我以为我理解了一些东西，花了几个小时投入到一个项目中，然后意识到，“错误，我以为我知道的并不完全适用于我的特定目标……废话。”

【参考方案1】：

架构支持两个主要目的：

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

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

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