方案一:每个表设计一个翻译表
数据库国际化的应用场景用到的比较少,主要用于对数据库的具体数据进行翻译,在需要有大量数据翻译的场景下使用,举个例子来说,力扣题目的中英文切换。参考方案可见:
- 灵活,能够为不同实体类型或者字段提供翻译支持,并可以很方便的对语言种类进行扩展
- 方便逆向查询:即根据翻译语言查出原始数据
缺点:
- 查询和管理可能更复杂,可能需要较多的联合查询
方案二:映射转换
使用映射的形式转换语言实现,绝大多数国际化程序的应用方案。举个例子说明映射式的翻译:你好 -> Hello。通过使用配置文件式存储对应关系,这种场景适用于国际化内容不怎么变化的场景,例如登录成功的提示信息,服务器出错的提示信息等。参考实现方案见下说明:
- 实现简单
缺点:
- 不够灵活,不方便对数据库的数据进行翻译,在添加新翻译数据时,需要修改代码。
虽然也可以对数据库的数据进行映射式的翻译,但是存在非常多的问题,比如线程安全和高并发情况下的效率过低问题。
方案三:JSON 存储
实现方式是通过对应翻译记录的表,新增一个国际化JSON字段来保存对应语言的翻译结果值。参考实现如下:
CREATE TABLE Products (
id INT PRIMARY KEY,
translations JSONB
);
示例JSON字段:
{
"en": {"name": "Product Name", "description": "Product Description"},
"zh": {"name": "产品名称", "description": "产品描述"}
}
优点:
- 灵活,能够存储任意数量的语言。
缺点:
- 查询和索引可能不如关系型字段高效,需要数据库支持 JSON 数据类型(当然也可以把翻译数据放在 MongoDB 中)
- 这种方式同样存在根据翻译字段查询原始数据不方便的问题
方案四:拦截器统一处理
实现解决方案,参考以下链接。
方案五:自定义注解转换