我正在开发一个数据库，其中包含来自许多不同应用程序的数据。在我的第一次设计过程中，我将每个临时表都放置在为其源应用程序命名的模式中。
由于几个源应用程序具有相似的数据和相似的表名，因此我使用模式名称来区分源应用程序。我正在考虑的替代方案是使用单个模式并在表名中包含源应用程序。
我想研究有关何时使用不同模式的设计规则以及这样做的利弊，但我找不到任何东西。
架构纯粹是为了许可和安全吗？
从组织的角度来看，在超出应用程序开发所需的不同模式中创建对象是否有意义，或者这只是不必要地增加了查询的复杂性？
这个决定是否有我忽略考虑的其他影响？
我将在这里提到逻辑和物理设计。
我知道出于管理原因，IBM 建议将暂存表放置到它们自己的模式中，甚至放置到它们自己的表空间中（在这种情况下，特定于 DB2 的数据库实现）。模式允许您通过分离关注点和安全性来更好地管理。表空间（物理设计）允许您更好地处理有关 REORG、RUNSTATS 和备份的维护问题。
虽然您可能没有实施 IBM DB2，但我认为他们的理念值得思考和实施。
根据您提供的描述，我认为安全性不是这里的问题。正如您所说，您的应用程序从多个来源接收数据。当您在该数据的检索/访问方法上具有基于角色的安全类型时，安全性就会出现/实施。我猜在将数据呈现给用户之前，必须首先进行某种整合、分析、协调等。
在这种情况下，单独的模式是保持源数据完整的最佳方式，不仅是在暂存期间，甚至是源数据的原始副本；以防万一您想稍后解决从特定来源收到的数据。
取决于数据提供者是什么，但如果这是财务数据，则提供者很可能会频繁更新源数据格式、添加/删除列等。如果多个来源同时开始执行此操作，如果您有一个统一的架构设计，则很难管理这些更改。但如果您有单独的架构，您就会知道这种更改不会影响其他源数据。
第二种情况，如果您希望您的应用程序作为源提供某种整合数据或将特定数据源提供给另一个子系统，那么使用单独的模式，您可以根据您想要共享的方式和内容获得更多的控制和灵活性。如果您有相同的架构；通过选择一些表、自定义角色或编写替代 API，共享数据将变得很痛苦。
拥有单独模式的缺点是您必须使用完全限定的对象名称来避免任何意外结果。此外，如果您有任何可能使用开放/分布式查询、链接服务器等的场景……请记住，它只允许两级对象名称解析。想想其他事情，比如 SQL 代理作业，以及您可能正在使用的其他功能，并检查它是否支持完全限定的对象名称解析。