【问题标题】：How to implement the "Shared database, separate schema" multi-tenant strategy如何实现“共享数据库，分离模式”多租户策略
【发布时间】：2011-03-22 14:31:34
【问题描述】：
我必须使用共享数据库分离模式方法启用 Web 应用程序多租户。该应用程序是使用 Java/J2EE 和 Oracle 10g 构建的。
我需要一个应用服务器，使用具有多个架构的共享数据库，每个客户端一个架构。
实现这一目标的最佳实施方法是什么？
- 中间层（应用服务器）需要做什么？
- 每个客户端是否需要多个主机头？
- 如何根据正在访问应用程序的客户端动态连接到正确的架构？
【问题讨论】：
标签：
java
database-design
cloud
saas
multi-tenant
【解决方案1】：
在高层次上，这里有一些需要考虑的事情：
- 您可能希望在日常开发中隐藏租赁注意事项。因此，您可能希望尽可能将其隐藏在您的基础架构中，并将其与您的业务逻辑分开。您不想总是检查您是否处于哪个租户的上下文中……您只想处于那个上下文中。
- 如果您使用的是工作单元模式，您需要确保任何工作单元（除了在纯粹的基础架构上下文中运行，而不是在业务上下文中运行的工作单元）都在一个租户的上下文中执行.如果您不使用工作单元模式……也许您应该使用。不确定您将如何遵循上述建议（尽管也许您能找到方法）。
- 您可能希望将租户 ID 放入每个消息传递或 HTTP 请求的标头中。在远离业务逻辑的原则下，最好将其保留在正文之外。您可以在幕后刮掉它，并确保在幕后将它放在任何传出的消息/请求上。
- 我不熟悉 Oracle，但在 SQL Server 中，我相信在 Postgres 中，您可以使用模拟作为切换租户的一种方式。也就是说，您可以只让一个 SQL 用户（没有关联的登录名）将关联租户的架构作为其默认架构，而不是在每个 SQL 命令和查询中参数化架构，然后将架构排除在外您的日常 SQL。您将不得不拦截对数据库的调用并将它们包装在模拟调用中。就像我说的那样，我不确定这在 Oracle 中是如何工作的，但这是 SQL Server 的总体思路。
- 身份验证和安全性在这里是一个大问题。这远远超出了我在这个答案中可以讨论的范围，但确保你做对了。