我在AdventureWorks数据库中看到不同的模式用于分组表。为什么会这样做（安全性等）？有没有最佳实践可以找到？
谢谢，Lieven Cardoen
1个回答
19
作为商业智能（Business Intelligence）的经理，我们依靠模式（schema）进行逻辑分组和管理安全性。以下是我们使用模式的一些情况：
逻辑组织
我们有一个常规数据库，由SSIS软件包仅用于在装载运营数据存储（ODS）之前暂存数据。在此数据库中，除了模式外，所有对象的结构（表名、列名、数据类型、可空性等）都与其原始来源相同。我们使用模式来指示表格的原始来源系统。在某些罕见情况下，两个不同的数据库具有具有相同名称的表格，而模式允许我们在暂存数据库中继续使用原始名称。
在我们BI服务器的每个数据库中，每个团队成员都有一个test_username模式。当我们在数据库中创建测试对象时，这使跟踪谁创建了对象变得容易。它还使清除测试对象变得容易，因为每个人都知道谁创建了什么。说实话，只要知道我们自己创建了它通常就足够了，特别是当我们无法记住何时或为何创建它时！
在我们的数据控制器数据库中，我们依靠模式来区分报告、ETL和通用资源之间的不同类型的过程。
在我们的星型模式数据仓库中，所有对象都被划分为维度和事实模式。
当我们向其他部门服务器推送数据时，我们将它们服务器上的所有BI（商业智能）对象使用bi模式。这使得非常容易知道BI负责加载和维护表格，即使它并不在我们的服务器上。如果目标服务器不是2008/2005 SQL Server框箱，则我们会在表名前缀加上bi_。
安全：
1. 由于我们是 BI 组，通常不建立和支持自己的应用程序。我们几乎完全使用其他人的应用程序，并从其后端数据库中获取数据到我们的服务器。但是，我们确实有一个名为 bi_applications 的数据库，它是各种小的 CRUD 应用程序的后端。这些应用通常是我们提供给业务方的数据输入表单，以便捕获我们否则需要在 BI 中维护的数据。这是一种将应该在生产应用程序中的数据获取到 BI 中的方法，同时等待低优先级应用程序增强在未来的开发清单中积灰。每个应用都有一个单独的模式，并且用于更新基础表的应用程序帐户仅有权访问相关模式的对象。这使得各个应用程序易于理解、安全和维护。
2. 在某些情况下，我允许高级用户直接访问我们的表或存储过程。我们依靠使用模式与角色结合来保护对象。我们授予权限给模式，并将用户添加到角色中。这使得我们能够轻松地了解哪些对象被谁使用，而无需深入挖掘角色以找出答案。
简而言之，当我们可能考虑将对象分离到自己的数据库中并且期望 BI 之外的应用程序或用户访问我们的数据库时，我们使用模式进行安全目的。
虽然这些不是最佳的应用开发业务实践，但我希望我的商业案例可以帮助您想到一些在业务终端使用模式的方法。
- InnerJoin
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接