带有默认语言环境的优雅本地化Java ORM

我们有一个用于UI目的的DTO；类似这样的Java POJO：

id

（跟踪的主键），

code

（非本地化属性）， 最值得注意的是，

name

和

description

。这两个属性需要本地化

我们需要一个实体和一个数据库模型来允许“元组”的本地化（

name

，

description

）。 我们在Oracle数据库中使用JPA，但通常会避免使用特定于供应商的功能。在Java中，我们更喜欢标准API查询。 如果非标准方法有很强的效益，我们会一直考虑它们。 I.–对数据库设计没有任何限制

对此，最直接的，或者（如果不同的话）性能最好的数据库模型和映射Java实体是什么

为给定的

id

和区域设置选择一行（

id

，

code

，

name

，

description

）的SQL是什么？返回

name

和

description

的值 如果请求的语言环境不是默认语言环境，并且此对象（

id

）的翻译尚不存在，则从默认本地化中获取？ API Java代码的标准是什么，即在给定的语言环境上下文中直接填充DTO？用例是一个正在列出 并非所有本地化数据都是德语的数据集，因此在某些行中，我们需要显示英文文本

我们更希望在数据库端做出回退决策。如果代码变得更干净或更多 可维护，或者查询更清晰或更快，我们可能会接受默认的本地化数据总是 传输到Java（即使并非在所有情况下都严格需要），以及所请求本地化的数据（如果需要和/或可用）。然而，我们确实会尽力避免 要获取所有区域设置的数据，因为大多数查询结果将“直接”进入UI，而无需任何缓存，呈现给 倾向于查看其个人区域设置中的所有数据

II.——特殊数据库设计

现在让我们假设一个关于数据库设计的附加需求。需要一个简单的表格来完成此任务 基本数据，以及默认的本地化文本数据-即，仅上述DTO映射到一个简单的数据库表，其中包含列

id

、

code

、

name

和

description

。 如果为默认语言环境（英语）请求数据，那么从该表中进行简单选择就足够了

非默认地区（例如德语）的所有本地化数据（

名称

，

说明

）应保存在其他地方（一个或多个附加表）。非本地化数据 属性，如上述

code

属性，应根据干燥状态进行存储，即不得重复

我倾向于称这种东西为“一对一或多”映射——这种设计的通用名称是什么？添加本地化数据（列）必须在多个表中完成这一事实是否可以强制执行

同样，在I.部分中，数据库和Java模型及查询（SQL和JPA/Criteria API）是什么样的