系统多语言实践(二)
转:http://blog.csdn.net/cassaba/article/details/21382193
1. 多语言存储
假设下面一个场景:
系统有一个产品目录需要维护,目录名称和描述需要支持多语言存储。表结构设计如下:
PRODUCT_CATEGORY |
|
|
|
|
PK | 栏位 | 类型 | 允许NULL | 描述 |
PK | ID | VARCHAR(36) | N | 类别Id |
| LANG_ID | VARCHAR(36) | N | 多语言ID |
| CREATED_ON | DATETIME | N | 创建时间 |
| CREATED_BY | NVARCHAR(50) | N | 创建人 |
| CHANGED_ON | DATETIME | Y | 变更时间 |
| CHANGED_BY | NVARCHAR(50) | Y | 变更人 |
针对每个需要支持动态多语言的表,除了创建一张主表,还需创建一个与之匹配的附表,命名规范为 {主表名}_M, M表示Multilingual的意思。
PRODUCT_CATEGORY_M |
|
|
| |
PK | 栏位 | 类型 | 允许NULL | 描述 |
PK | ID | VARCAHR(36) | N | 关联主表的LANG_ID栏位 |
PK | CULTURE_CODE | VARCHAR(10) | N | 区域代码 |
| NAME | NVARCHAR(50) | N | 类别名称 |
| DESCRIPTION | VARCHAR2(500) | Y | 类别描述 |
2. 多语言维护
用户在维护需要支持多语言数据的栏位的时候,需要根据系统支持的多语言种类,一次录入多笔资料。
为了保证UI的一致性,可以开发js版本的多语言控件。如下图:
3. 多语言访问
由于设计的时候,严格遵循了一致的Schema设计和命名规范,我们可以通过代码生成工具自动生成关联查询语句,使得M表对于开发者透明。
4. 其它
在网上有金蝶K3 Cloud中的设计:
http://open.kingdee.com/K3Cloud/PDM/BD.htm