Java 使用JPA在运行时更改表名

我实现了一个使用数据库的服务。数据库中几乎没有表。在这些表中存储一些计算结果。另一个服务为每次计算创建一个新表，现在表列表如下所示：

CREATE VIEM my_common_name AS
SELECT '1_0' as calc_name, t.* FROM calculation_1_0 t UNION ALL
SELECT '2_0' as calc_name, t.* FROM calculation_2_0 t UNION ALL
.....
.....
SELECT 'X_Y' as calc_name, t.* FROM calculation_X_Y t

• 计算1\u 0
• 计算2\u 0
• 计算2\u 1
• 计算
• 计算3\u 0
• 计算

所有表的表结构都相同

---

是否可以使用JPA从这些表中获取数据，而无需为每个表创建实体

在运行时创建表是个坏主意。如果您知道列是什么，更好的设计是使用

计算类型

查找表，并在计算表中创建外键并对其进行索引。然后，您可以提前创建实体，并具有更好的关系完整性

为了直接回答这个问题，不能动态创建新表，然后使用JPA进行映射。您可以使用普通的JDBC，但JPA不支持它是有原因的——它的设计很糟糕

---

@克罗科蒂尔科我完全同意你的看法，但我对你的行为不负责任 改变设计结构，因为我不是it开发人员，我只是 用它来实现我的目标

如果你必须接受它，那么我会动态地删除/创建一个视图或同义词来欺骗JPA。其想法是：

• 在加载EntityManager之前，创建一个具有固定名称的视图/同义词，该视图/同义词将所选表映射到该通用名称
• 在JPA中，使用XML或注释将实体映射到视图/同义词的通用名称
• 加载实体管理器

这种方法有缺点：

• 只有应用程序的一个实例/线程可以同时使用此视图/同义词，这在多用户环境中不起作用（除非所有实例/线程都是同步的，并且在更新/重新创建视图时会同时关闭/打开实体管理器-但我甚至无法想象这样的解决方案，否则这将是一个包含许多陷阱和错误的大型项目）
• 一次只能使用一个表，为了使用另一个表，必须关闭实体管理器，删除视图/同义词，然后再次创建，然后再次加载实体管理器

---

您还可以创建一个视图来合并多个表，如下所示：

CREATE VIEM my_common_name AS
SELECT '1_0' as calc_name, t.* FROM calculation_1_0 t UNION ALL
SELECT '2_0' as calc_name, t.* FROM calculation_2_0 t UNION ALL
.....
.....
SELECT 'X_Y' as calc_name, t.* FROM calculation_X_Y t

但同样-如果流程创建新表，则必须关闭实体管理器，使用新表名重新创建此视图，然后再次加载实体管理器。

从性能的角度来看，这将非常糟糕-您无法在此视图上创建任何索引，无法对其进行分区、优化或具体化，针对此monster视图的每个查询几乎总是对所有这些表进行完整的表扫描

---

一开始就做了一个糟糕的数据库结构设计，就像设计带有不同充电插座的手机一样，每次给手机充电时都需要使用不同的插头。最好的办法是修复这个原始错误，因为这样的修复非常容易，只需创建一个带有附加项的公用表即可al Colu“calculation_name”并修复了将数据保存到这些表中的代码（将数据插入到公共表中，而不是每次都创建新表），其他一切都将是绕过此问题的麻烦尝试

---

如果我是你，我会去找我的经理，我会告诉他有一个设计糟糕的技术问题。我会告诉他我们现在可以解决它，而且会花费一点（$）。我会告诉他，如果我们现在不解决它，那么这个功能未来的每一次更改都会越来越麻烦和昂贵（$$，$$$，$$$-由于工时、维护、性能/硬件等方面的成本），最终这样的修复将是不可能的，我们将不得不从头重写此系统（这将花费我们$）。

---

经理有更广阔的视野，他应该知道商业计划，他应该知道这个功能将来是否会开发出来，或者可能在半年后被放弃。这是经理的决定-现在投资美元，将来节省美元，或者什么都不做，因为这不会给我们带来任何利润。

非常糟糕的表结构正确的设计。只有一个表有“计算编号”列其中我们记住了计算数字，例如3_0、2_1等。重新设计模型，这是最好、最简单的解决方案。@krokodilko我完全同意你的观点，但我不负责更改设计结构，因为我不是它的开发人员，我只是为了我的目标而使用它。