多语言系统的数据库设计问题

[dna_xp]

公司需要设计的系统是多语言的，碰到数据库设计的问题，我能想到的是有两种方案“
1、表格根据不同的语言设置多个字段，比如
en_name zh_name
-------------------------------------------------------------
Appointment 预约
2、相同的字段但是通过多条记录加上一个语言字段来判断，比如
NAME LNG CODE
-----------------------------------------------------------------
Appointment en 1
预约 zh 1

第一种方案如果以后再加种语言就要修改表结构，需要动态根据语言环境取得字段内容；第二种方案后台数据维护非常麻烦，而且数据量成倍增加，还会存在数据不同步的问题。

各位做过的兄弟，有什么好的建议

[rtdb]

看你这个多语言有多高要求了， 其实一般所谓的多语言，是指提供多种语言的版本，系统还只是一种语言。 若想同时支持多种语言，难度很高，系统也很难维护，这时方案2要好一些。

[dna_xp]

我一开始也是采用方案2，但是在设计后台管理模块的时候就发现很是麻烦

[正宗熊猫哥]

系统设计的初衷是解决什么问题，面对语言哪些，之后后期扩展满足表或程序可调整就是了。。想太多累人

[ksy]

推荐第二种，因为不需要修改表结构； 就算一个系统有10万个词、10种语言，也不过100万条记录，所以记录量不是问题，即便 有更多的记录，设置好表索引，快速读取也不是问题； 多语言通常不会频繁更新，所以可以利用缓存高效访问； 如果程序在发布后不需要修改多语言内容，甚至可以用T4模板生成多语言资源的静态类。

[dna_xp]

第二种方案的话，后台数据管理怎么作呢？页面设计和数据同步又是个问题

[dna_xp]

我所指的多语言环境并不是单单的对于页面上固定的按钮、菜单这种东西，而是具体到每条内容纪录。

[rtdb]

引用 8 楼 dna_xp 的回复:

我所指的多语言环境并不是单单的对于页面上固定的按钮、菜单这种东西，而是具体到每条内容纪录。

在一个系统内每个数据都提供多语言是不可能完成的任务。 实际上都是提供多套系统， 每语言一套。 那些提供多语言的网站，当你换语言时，实际上你就被连去了另一个网站。

[dna_xp]

网站可能是多个，但是后台管理如果搞成多个，那就太麻烦了。

[xboxeer]

参考siebel里面的做法（siebel是oracle的CRM套件,所以你大可放心这种做法是否可靠) 首先 程序全局有个语言变量 （en,cn,jpn等等) 然后 每个需要用到语言的地方（比如按钮title，提示信息，字段title）都有三个属性，StringOverride, StringReference, String 然后单独一张存储语言信息的表，大概下面这个样子 LanguageCode, StringReference, String EN OK_BUTTON_TITLE OK CN OK_BUTTON_TITLE 确定 然后你在设计页面时候 OK按钮就根据情况， 就只要设置StringReference就可以了，然后程序根据当前全局的语言变量来决定用OK还是确定 如果希望所有语言都是一样的显示 你就可以用 StringOverride, 强制忽略LanguageCode

[xboxeer]

引用 8 楼 dna_xp 的回复:

我所指的多语言环境并不是单单的对于页面上固定的按钮、菜单这种东西，而是具体到每条内容纪录。

如果你的意思是不同语言看到的记录不一样那你只要根据全局的LanguageCode在取记录的时候加一个筛选条件就可以了。。。 如果你的意思是不同语言看到记录是一样的但是内容自动翻译为不同的语言。。。那这种需求没法满足。。。最多最多，根据上面提到的根据全局LanguageCode来筛选记录提供同样内容记录的不同语言版本。。。

[xxoo2007]

有点奇怪这个需求，用户录入的是什么？中文还是英文？你还需要识别用户录入的语言再确定写哪个字段么？ 一般来说第一种方案足够了，因为常规不同的语言有不同的UI，加一种语言，需要加一套UI，所以加字段不是个大事了

[zbdzjx]

理论上说第二种更合理，但实际上，这两种差别应该不大。 就像第一种，多增加一个语言就多增加一列，填好文字。代码中多一点点判断就OK了。

[以专业开发人员为伍]

如果纠结于“只能用一个表处理多语言增加”你才会有这个烦恼。 但是实际上，前端界面并不是像访问普通的业务数据那样频繁访问数据库的。因此这种想法数据结构看似合理，其实不实用。 前端程序其实仅仅需要在程序初始化时访问“一次”，读取全部（比如说60个）记录而已。 第一种情况 当前语言 对应中文（主键） ------------------------------------------------------------- Appointment 预约 这就行了。开发时以中文为基准，然后不同语言各有一份这个表的copy（表名不同），分别表示单词与中文单词对应关系。 并且，前端程序肯定是一次性下载整个表的。

[以专业开发人员为伍]

引用 楼主 dna_xp 的回复:

第一种方案如果以后再加种语言就要修改表结构，需要动态根据语言环境取得字段内容；第二种方案后台数据维护非常麻烦，而且数据量成倍增加，还会存在数据不同步的问题。

第二种方案太技术化了，就是劳民伤财的。 第一种方案中，当增加一种语言时，你不应该增加字段，而是应该 create table ......，创建有着完全一模一样结构的另外一个表。而读取时就是select * from [...] 的sql语句拼接的表名不一样而已。从手工录入数据、事后维护数据来看，都是非常直观。

[以专业开发人员为伍]

另外一种更好的方案，其实是每种语言都弄一个简单的文本文件供客户端下载就行了。 就算是你把文本文文件放到数据库表的不同字段中，例如“语言(nvarchar)、文件内容(text)”两个字段也行。 这个东西目前基本上是一次性的“死数据”，不能跟每天新增上万条记录的用户大量业务数据相比。不一定要放到数据库里。

[bluedoctor]

引用 16 楼 sp1234 的回复:

[quote=引用 楼主 dna_xp 的回复:] 第一种方案如果以后再加种语言就要修改表结构，需要动态根据语言环境取得字段内容；第二种方案后台数据维护非常麻烦，而且数据量成倍增加，还会存在数据不同步的问题。

第二种方案太技术化了，就是劳民伤财的。 第一种方案中，当增加一种语言时，你不应该增加字段，而是应该 create table ......，创建有着完全一模一样结构的另外一个表。而读取时就是select * from [...] 的sql语句拼接的表名不一样而已。从手工录入数据、事后维护数据来看，都是非常直观。[/quote] 这种方案很好!

[king4323210]

这些方案都不好 我推荐用二个字段，一个标识，一个数据 根据标识找到数据。 比如：标识 数据 c <datatype="zh-c" ><datatype="zh-cn" name="中文" /><datatype="zh-cs" name="葡萄牙" /></datatype> 首字母的放一个xml结构中 sql支持xml查询

[king4323210]

你需要做的就是写一个 解析器

[於黾]

同样不明白所谓多语言,到底是按钮,标题多语言,还是连数据都多语言 如果仅仅是界面多语言,完全可以用语言包 如果是webform,最好还是做成多套网站 毕竟不同语言占的宽度都不一样,仅仅替换文本,可能会导致整个界面错乱

[本拉灯]

其实第一种方案是最好维护的。唯一麻烦的就是他如果增加语言时要加字段。我们现在也是用第一种方案，不过创建字段都好办 用SQL去动态创建字段。这样在后面维护语言标签时一目了然。