什么时候适合使用单独的模式进行数据库设计？

Question

我正在开发一个数据库，其中的数据来自许多不同的应用程序。在我的第一次设计中，我将每个临时表放置在以其源应用程序命名的模式中。

由于多个源应用程序具有相似的数据和相似的表名称，因此我使用架构名称来区分源应用程序。我正在考虑的替代方案是使用单个架构并在表名称中包含源应用程序。

我想研究有关何时使用不同模式的设计规则以及这样做的利弊，但我找不到任何东西。

该架构纯粹是为了许可和安全吗？

从组织的角度来看，在超出应用程序开发所需的单独模式中创建对象是否有意义，或者这只是不必要地增加查询的复杂性？

这个决定是否还有我忽略考虑的其他影响？

Answer 1

从您给出的描述来看，我认为安全不是这里所关心的问题。正如您所说，您的应用程序从多个来源接收数据。当您在该数据的检索/访问方法上具有基于角色的安全类型时，安全性就会出现/实现。我猜测在将数据呈现给用户之前必须首先进行某种整合、分析、协调等。

在这种情况下，单独的模式是保持源数据完整的最佳方法，不仅在暂存期间，甚至在源数据的原始副本期间也是如此；以防万一您想稍后对从特定来源收到的数据进行故障排除。

取决于数据提供商是什么，但如果这是财务数据，则提供商很可能经常更新源数据格式、添加/删除列等。如果多个源同时开始执行此操作，并且您有一个统一的模式设计，那么管理这些更改将很困难。但如果您有单独的架构，您就会知道此更改不会影响其他源数据。

第二种情况，如果您希望应用程序作为源提供某种整合数据或将特定数据源提供给另一个子系统，那么使用单独的模式，您可以在共享方式和共享内容方面拥有更多控制权和灵活性。如果您有相同的架构；通过选择某些表、自定义角色或编写备用 API，共享数据将变得很痛苦。

拥有单独模式的缺点是您必须使用完全限定的对象名称以避免出现任何意外结果。另外，如果您有任何可能使用开放/分布式查询、链接服务器等的情况...请记住，它只允许两级对象名称解析。考虑其他事情，例如 SQL 代理作业以及您可能使用的其他功能，并检查它是否支持完全限定的对象名称解析。