在 SQL Server 中使用架构的最佳实践 (2008)

Question

我可以在 AdventureWorks 数据库中看到不同的模式用于对表进行分组。为什么要这样做（安全性，...？），我能找到最佳实践吗？

谢谢，利文·卡登

Answer 1

作为商业智能的经理，我们依靠架构进行逻辑分组和管理安全性。以下是我们如何使用模式的一些案例：

逻辑组织

1. 我们有一个由 SSIS 包加载的通用数据库，仅用于在加载操作数据存储 (ODS) 之前暂存数据。在这个数据库中，除了模式之外，所有对象的结构（表名、列名、数据类型、可空性等）都与它们的原始源相同。我们使用模式来指示表的原始源系统。在极少数情况下，两个不同的数据库具有相同名称的表，并且架构允许我们继续在暂存数据库中使用原始名称。

2. 在我们的 BI 服务器上的每个数据库中，每个团队成员都有一个 test_username 架构。当我们在数据库中创建测试对象时，这可以很容易地跟踪谁创建了对象。由于每个人都知道谁做了什么，因此以后清除测试对象也变得容易得多。坦率地说，只要知道我们制作了它通常就足以知道它可以安全地删除，尤其是当我们不记得我们何时或为什么制作它时！

3. 在我们的数据控制器数据库中，我们依靠模式来区分报告、etl 和通用资源之间的不同类型的流程。

4. 在我们的星型模式数据仓库中，所有对象都分为维度模式和事实模式。

5. 当我们将数据推送到其他部门服务器时，我们使他们服务器上的所有 BI 对象都使用架构 bi。即使它不在我们的服务器上，这也使得了解双向加载和维护表变得非常容易。如果目标服务器不是 2008/2005 SQL Server 机器，那么我们在表前加上 bi_。

当涉及到它时，我们会在任何时候使用模式进行逻辑组织，我们会在对象上附加前缀或后缀以帮助在没有模式的情况下组织它。话虽如此，在某些情况下，我们不在 BI 服务器上使用模式。在我们的 WorkingDB 中，一切都是 dbo。我们的 WorkingDB 与 TempDB 一样用于创建临时表，但这些表是我们知道每次 ETL 流程运行时都会创建的临时表。 WorkingDB 的特殊属性是我们从不备份数据库，并且所有使用数据库的 ETL 进程必须能够在没有表的情况下从头开始重新创建它们的对象。在这种情况下，我们认为使用模式并没有增加任何组织价值，因为我们实际上并没有在其临时 ETL 流程之外使用对象。

安全

1. 由于我们是一个 BI 小组，我们通常不会构建和支持我们自己的应用程序。我们几乎只使用其他人的应用程序，并将数据从他们的后端数据库带到我们的服务器。但是，我们确实有一个名为 bi_applications 的数据库，它是各种小型 CRUD 应用程序的后端。这些应用程序通常是我们提供给业务的数据输入表单，以便它们可以捕获我们原本必须在 BI 中维护的数据。这是一种将生产应用程序中的数据获取到 BI 中的方法，同时我们等待我们的低优先级应用程序增强功能在未来的开发列表中收集灰尘。每个应用程序都有一个单独的模式，用于更新基础表的应用程序帐户只能访问关联模式的对象。这使得理解、保护和维护单独的应用程序变得非常容易。

2. 在少数情况下，我让高级用户可以直接访问我们的表或存储过程的数据库。我们依靠结合使用模式和角色来保护对象。我们授予架构权限，并将用户添加到角色中。这使我们可以轻松了解哪些对象由谁使用，而无需深入研究角色。

简而言之，当我们可能考虑将对象分离到它们自己的数据库中并且我们希望 BI 之外的应用程序或用户访问我们的数据库时，我们出于安全目的使用架构。

虽然这些对于应用程序开发人员来说并不是最佳业务实践，但我希望我的双向用例可以帮助您思考在业务结束时使用架构的一些方法。