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

Question

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

thx，利文·卡杜恩(Lieven Cardoen)

Answer 1

作为商业智能的管理者，我们依靠模式进行逻辑分组和管理安全性。以下是一些有关如何使用模式的情况:

逻辑组织

我们有一个由SSIS程序包加载的常规数据库，仅用于暂存数据，然后再加载操作数据存储(ODS)。在该数据库中，除了架构之外，所有对象的结构(表名称，列名称，数据类型，可空性等)都与其原始来源相同。我们使用该模式指示表的原始源系统。在极少数情况下，两个不同的数据库具有名称相同的表，并且架构允许我们继续在登台数据库中使用原始名称。

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

在我们的数据 Controller 数据库中，我们依赖于架构将报表，etl和常规资源之间的不同类型的流程分开。

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

当我们将数据推送到其他部门服务器时，我们使它们服务器上的所有BI对象都使用架构bi。这样就很容易知道bi加载和维护表，即使它不在我们的服务器上也是如此。如果目标服务器不是2008/2005 SQL Server框，则我们在表前加上bi_。

归根结底，只要有一个对象附加前缀或后缀，就可以在没有模式的情况下使用模式进行逻辑组织。话虽如此，在某些情况下，我们没有在BI服务器上使用架构。在WorkingDB中，一切都是dbo。我们的WorkingDB像TempDB一样用于创建临时表，但是这些表是我们知道每次ETL流程运行时都会创建的临时表。 WorkingDB的特殊属性是，我们永远不会备份数据库，并且使用该数据库的所有ETL流程必须能够在没有表的情况下从头开始重新创建其对象。在这种情况下，我们认为使用架构并没有增加任何组织值(value)，因为我们实际上并未在其临时ETL流程之外使用这些对象。

安全性

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

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

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

尽管对于应用程序开发人员而言，这些并不是最佳的业务实践，但我希望我的双用例可以帮助您想到在业务结束时使用模式的一些方法。