我正在使用 Play Framework 开发一个项目，该项目需要我创建一个多用户应用程序。我有一个中央面板，我们在其中为团队添加了某个研讨会。问题是，我不知道这是否是最好的方法，但我想生成像
team1_tablename 团队1_secondtable..
然后，当某个请求使用虚拟主机（例如http://teamawesome.workshop.com）命中时，我需要将查询操纵到该特定表。
问题不是生成表格，而是使用模型。所有的研讨会都将有相同的通用表格。在模型中，我必须说明表格等，但是如果这是带有教义的 PHP，我将在创建车间 team1 后创建一个模板，但在 java 中，即使我生成它们，我也必须编译它们，这需要我要做更多的研究。
我的问题更多是面向休眠的，然后在这里跳枪并放弃可能的解决方案。我全是耳朵
我曾想过使用 NamedQueries，我不知道我是否误读了，但我在一本休眠书中读到，您可以查询然后将结果添加到通用模型中，然后我使用该模型来保留我的所有结果......
如果有任何疑问，请告诉我，谢谢（注意这不是一个多数据库问题，只是使用具有唯一前缀的不同表集）
我想知道您是否可以使用一组表，但在每个表中都有类似 TEAM_ID 作为外键。
您将需要一个 TEAM 表，其中 TEAM_ID 将是主键。这将被迁移到表并成为外键的一部分。
例如，如果你有一个 Player 实体，有一个 HighScores 集合，那么在 DB 中，Player 表将有一个 TEAM_ID（来自 Team 表的外键），而 HighScores 表将有一个组合外键（Player_id，Team_id）来自玩家桌..
因此，最重要的是，我建议对您的数据库进行逻辑分区，而不是物理分区（正如您最初考虑的那样）。
希望这是有道理的，它肯定需要更多的思考，但如果你认为这是一个有趣的想法，我可以更详细地考虑一下。
我熟悉 Hibernate 和另一个 Web 框架，以下是我的处理方式：
我会为一个团队创建一组表格来满足我的所有需求。然后我会：
使用 DB2：为每个团队创建一个模式，将一组表复制到每个模式中。
使用 MySQL：为每个将一组表复制到每个表中创建一个新数据库。注意：MySQL 中的“数据库”更像其他数据库中的模式。（对不起，我宁愿让事情太简单也不愿错过重点）
现在您可以为每个连接设置一个单独的 hibernate.cfg.xml 文件（这并不是最好的方法，但也许是最好的开始，因为它非常简单）。现在您可以指定连接参数...包括架构/数据库。现在您的实体表，假设它被称为“团队”，它将在它连接的任何地方使用“团队”表......
为了快速开始，当用户登录时，在他们的会话中创建一个用户对象。用户对象将有一个 Hibernate SessionFactory，它将用于从正确的 hibernate.cfg.xml 文件构建的所有数据库请求，该文件通过解析登录中使用的 URL 来确定。
一旦上面的工作......有一些严重的效率问题需要解决。那就是每个登录的用户都在创建一个 SessionFactory ...如果没有很多并发使用，也许这不是问题，但您可能想在那时查看 Spring 并为每个团队使用一个连接池。这样，每个团队就有一个 Session 工厂，并且在用户登录时不会创建主要对象。
这个解决方案的好处是创建新的表集应该更容易，因为每个表集都存在于它自己的世界中。将只有一组实体类，而不是每个团队和表的产品。数据库模式保持相当简单，不会因为添加团队名称和所需的约束而变得复杂。如果团队需要数据所有权和隐私，那么将数据库移动到不同的位置将相当容易。
不利的一面是，如果需要为团队更改模型，则必须为每个团队完成（而不是使用 teamName 作为外键的单个表集）。
为每个团队使用不同表的想法（尽管成功的应用程序可能会使用它）老实说非常幼稚，并且当您考虑维护时会遇到严重的缺陷......想想如果您发现自己需要您将被迫做什么一个新表，甚至只是一个索引......您最终需要将 DML 脚本编写为模板，并使用一些（自定义）软件在所有团队中运行它们......
正如其他答案（Quaternion's and Octav's）中提到的，我认为你有两个可行的选择：
要选择最适合您的选项，您必须确定“团队”是否真的是您可以将数据集划分为的东西，或者它是否真的是您想要引入数据模型的另一个实体。
您可能已经注意到我在这里使用的是“拆分”而不是“分区”——这是因为 DBA 通常使用后一个术语来表示我们可以称之为“分片”的内容——“拆分”旨在成为一个更强大的术语。
拆分仅在以下情况下可行：
正如您可能看到的那样，这种意义上的拆分并不是很有吸引力（也许现在可以，但是当您发现自己想要添加新功能时呢？），所以我的建议是“团队是一个实体” “解决方案。
另请注意，维护一组数据库/模式实际上比维护单个（尽管可能更复杂）数据库更难......再次考虑在生产系统中添加索引应该采取哪些步骤......
如果您最终拥有多个前端（可能是由于特定客户的定制），单数据库解决方案的唯一缺点就会显现：对共享数据库的更改可能会影响所有使用它的应用程序，因此您可能需要协调升级到不同的 web 应用程序以最大程度地降低风险（但是请注意，在大多数情况下，您可以在不破坏兼容性的情况下更改数据库）。
毕竟，一无所获，就陷入黑暗，这有点令人沮丧。不过现在我已经开始工作了，我试着完成。我认为您可以通过以下解决方案完成工作：
写了一个PlayPlugin并确保您将每个请求添加到团队的请求args中。然后你写了你自己的NamingStrategy. 在NamingStrategy您可以阅读request.args并将团队放入您的表名中。取决于你如何添加它Team _ 或Team。这将是您首选的解决方案或带有架构的东西。听起来你有一个 db-schema，所以它可能是保留这些表而不迁移的最佳解决方案。
Please make the next time your request more abstract so that you can provide some information like how many tables, is team an entity and how much records a table has (max, avg, min). How stable is your table model? This are all questions which helps to give a clear recommendation with arguments.
您可以尝试模块 vhost，但似乎维护得不是很好。但我认为将团队名称放入表名的想法确实很奇怪。Postgres 和 Oracle 有这方面的模式。所以你使用 myTeam.myTable。但是你必须自己做坚持。另一种方法是不同的数据库，但同样你没有很好的支持。我会试试这个