可翻译 Hibernate 模型的设计模式
我有一个 Hibernate 模型，它（简化的）看起来像这样：
public class CoverageLine {
private Long id;
private String coverageText;
private boolean coveragePresetTo = true;
private OnNewPolicy onNewPolicy = OnNewPolicy.SHOW;
}
我需要coverageText可以（由最终用户）翻译成任意多种语言，但使用相同的ID，这样我就可以请求一个策略（这些行是添加）英语或德语，并具有 getCoverageText() 返回的文本的相关版本。其他字段在数据库中不可翻译，它们是使用资源文件进行翻译的，因此数据库中对象的多个版本是不可取的。
我的暂定计划是创建一个 JSON clob 字段，并将所有值存储在其中 ([{"lang":"en","value","...."}],[{"lang":"de “ ...}]），将语言设置为瞬态字段，并使用 get/set 方法操作 JSON，但这实际上并不具有最佳实践的感觉。或者，拥有第二个包含行 ID、语言和字符串的表，但这有可能使我的数据模型大大膨胀，而仅仅是拥有更多 SQL-y 数据。
有什么建议吗？
I have a Hibernate model that (simplified) looks like this:
public class CoverageLine {
private Long id;
private String coverageText;
private boolean coveragePresetTo = true;
private OnNewPolicy onNewPolicy = OnNewPolicy.SHOW;
}
I need coverageText to be translatable (by the end-user) into arbitrarily many languages, but using the same ID, such that I can request a policy (to which the lines are added) in either English or German, and have the relevant version of the text returned by getCoverageText(). The other fields are not translatable in the database, they are translated using resource files, so multiple versions of the object in the DB isn't desirable.
My tentative plan is to make a JSON clob field, and store all the values in that ([{"lang":"en","value","...."}],[{"lang":"de" ...}]), set the language as a transient field, and manipulate the JSON using the get/set methods, but that doesn't really have the feel of a best practice. Alternatively, to have a second table with line-id, language and string, but that has the potential of inflating my data-model considerably for little more than having more SQL-y data.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将所有选择发送到用户界面并不是我的第一选择。
一种方法是将措辞存储在表中。覆盖率表将有一个语言列外键来选择您正在处理的语言。该值将被加载到对象中，然后您就完成了。
缺点是区域设置更改需要往返于服务器、数据库和返回。
Spring 通过与语言环境相关的视图来实现这一点。也许你也可以尝试一下。
Sending all the choices down to the UI would not be my first choice.
One way would be to store the verbiage in a table. The Coverage table would have a language column foreign key to pick out which language you were dealing with. The value would be loaded into the object and you'd be done.
The downside is that a locale change would require a round trip to the server, database, and back.
Spring accomplishes this with locale-dependent views. Maybe you can try that as well.