我可以在AdventureWorks数据库中看到不同的模式用于对表进行分组。为什么要这样做（安全性，......？）并且我能找到最佳实践吗？
thx，Lieven Cardoen
答案 0 :(得分：18)
作为商业智能的经理，我们依靠模式进行逻辑分组和管理安全性。以下是我们如何使用架构的一些案例：
逻辑组织
在加载运营数据存储（ODS）之前，我们有一个SSIS包加载的通用数据库，仅用于暂存数据。在此数据库中，除了模式之外，所有对象在结构（表名，列名，数据类型，可空性等）中都与其原始源相同。我们使用模式来指示表的原始源系统。在一些罕见的情况下，两个不同的数据库具有相同名称的表，并且模式允许我们继续在登台数据库中使用原始名称。
在BI服务器上的每个数据库中，每个团队成员都有一个test_username架构。当我们在数据库中创建测试对象时，可以很容易地跟踪制作对象的人。它还使得以后清除测试对象变得更加容易，因为每个人都知道谁做了什么。坦率地说，只要知道我们制作它通常就足以知道它可以安全删除，特别是当我们不记得我们何时或为什么制作它时！
在我们的数据控制器数据库中，我们依靠模式在报告，etl和通用资源之间分离不同类型的流程。
在我们的星型模式数据仓库中，所有对象都分为维度和事实模式。
当我们将数据推送到其他部门服务器时，我们会使其服务器上的所有BI对象都使用架构bi。这使得很容易知道bi负载并维护表，即使它不在我们的服务器上。如果目标服务器不是2008/2005 SQL Server框，那么我们在表前加上bi _。
当它归结为它时，我们在逻辑组织中使用模式随时我们将一个前缀或后缀附加到一个对象，以帮助在没有模式的情况下组织它。话虽如此，但有一些情况我们不在BI服务器上使用架构。在我们的WorkingDB中，一切都是dbo。我们的WorkingDB像TempDB一样用于创建临时表，但这些表是临时表，我们知道每次运行ETL进程时都会创建这些表。 WorkingDB的特殊属性是我们不会备份数据库，并且所有使用数据库的ETL进程必须能够在没有表的情况下从头开始重新创建对象。在这种情况下，我们觉得使用模式没有添加任何组织值，因为我们实际上并没有使用临时ETL过程之外的对象。
安全
由于我们是BI组，因此我们通常不会构建和支持自己的应用程序。我们几乎专门使用其他人的应用程序，并将数据从后端数据库传输到我们的服务器。但是，我们确实有一个名为bi_applications的数据库，它是各种小型CRUD应用程序的后端。这些应用程序通常是我们提供给业务的数据输入表单，以便它们可以捕获我们原本必须在BI中维护的数据。这是一种将应该在生产应用程序中的数据导入BI的方法，同时我们等待我们的低优先级应用程序增强功能来收集未来开发列表中的灰尘。每个应用程序都有一个单独的模式，用于更新基础表的应用程序帐户只能访问相关模式的对象。这使得理解，保护和维护单独的应用程序变得非常容易。
在少数情况下，我让高级用户可以直接访问我们的表或存储过程。我们依赖于使用与角色结合的模式来保护对象。我们为架构授予权限，并将用户添加到角色。这使我们可以轻松地了解哪些对象被谁使用，而无需挖掘角色来解决问题。
简而言之，我们可能会考虑将对象分离到自己的数据库中，以及当我们期望BI之外的应用程序或用户访问我们的数据库时，出于安全目的使用模式。
虽然这些不是应用程序开发人员的最佳业务实践，但我希望我的双用例可以帮助您考虑在业务结束时使用模式的一些方法。