首页 考试吧论坛 Exam8视线 考试商城 网络课程 模拟考试 考友录 实用文档 求职招聘 论文下载 | ||
2011中考 | 2011高考 | 2012考研 | 考研培训 | 在职研 | 自学考试 | 成人高考 | 法律硕士 | MBA考试 MPA考试 | 中科院 |
||
四六级 | 职称英语 | 商务英语 | 公共英语 | 托福 | 雅思 | 专四专八 | 口译笔译 | 博思 | GRE GMAT 新概念英语 | 成人英语三级 | 申硕英语 | 攻硕英语 | 职称日语 | 日语学习 | 法语 | 德语 | 韩语 |
||
计算机等级考试 | 软件水平考试 | 职称计算机 | 微软认证 | 思科认证 | Oracle认证 | Linux认证 华为认证 | Java认证 |
||
公务员 | 报关员 | 银行从业资格 | 证券从业资格 | 期货从业资格 | 司法考试 | 法律顾问 | 导游资格 报检员 | 教师资格 | 社会工作者 | 外销员 | 国际商务师 | 跟单员 | 单证员 | 物流师 | 价格鉴证师 人力资源 | 管理咨询师考试 | 秘书资格 | 心理咨询师考试 | 出版专业资格 | 广告师职业水平 驾驶员 | 网络编辑 |
||
卫生资格 | 执业医师 | 执业药师 | 执业护士 | ||
会计从业资格考试(会计证) | 经济师 | 会计职称 | 注册会计师 | 审计师 | 注册税务师 注册资产评估师 | 高级会计师 | ACCA | 统计师 | 精算师 | 理财规划师 | 国际内审师 |
||
一级建造师 | 二级建造师 | 造价工程师 | 造价员 | 咨询工程师 | 监理工程师 | 安全工程师 质量工程师 | 物业管理师 | 招标师 | 结构工程师 | 建筑师 | 房地产估价师 | 土地估价师 | 岩土师 设备监理师 | 房地产经纪人 | 投资项目管理师 | 土地登记代理人 | 环境影响评价师 | 环保工程师 城市规划师 | 公路监理师 | 公路造价师 | 安全评价师 | 电气工程师 | 注册测绘师 | 注册计量师 |
||
缤纷校园 | 实用文档 | 英语学习 | 作文大全 | 求职招聘 | 论文下载 | 访谈 | 游戏 |
本文概述了在数据库设计中,如何处理多国语言的问题,这里的多国语言是指诸如这样的业务:在ERP软件中,我们在填写客户名称时,除了需要填写客户的中文名称,还需要填写他的英文名称。 一般的,如果是普通的项目型软件,就比较简单了,你只需要设计出固定的 ChineseName和EnglishName字段就可以了。本文并不讨论这种形式,而是讨论在大型平台化的ERP软件中如何实现通用化的多语言存储和读取。
子表方式
第一种方式是建立一张子表,U9大概就是这个样子,你需要注意的是,每一个实体如果包含多语言字段,都会出现以_Trl为后缀的表。也许你会觉得麻烦,其实不然,这些都是平台在后台自动处理了,你仅仅需要标记这个字段是多语言字段就可以了。
从理论上来说,他的存储是最符合数据库设计原则的,不管你的系统使用多少语言,数据库结构是不变的。但是我总觉得查询起来SQL会比较复杂,虽然这事平台也会帮助你完成。我在想,如果我要一个多语言策略如何实现呢?多语言策略的例子:如果此字段没有对应的繁体中文,取简体中文,如果还没有,取默认的语言内容。那么在一个SQL中如何实现呢?
不管怎么样,至少我不喜欢这种。
多字段模式
恩?这是哪门子设计?和我上面讲的项目型设计不是一样吗?
数据结构是一样的,唯一的区别是通过ORM屏蔽了数据库的结构,在设计实体时,你仅仅设计了Name字段,其类型是“多语言类型”,然后在客户那里初始化时,客户可以决定采用多少种语言,然后ORM在后台自动添加这些列。
这是我希望的设计,因为他足够的简洁,任何人都可以非常方便的写出SQL语言。而且执行起来一定是最高效的。而且实现上面说的取值策略也很容易,只需要实现编排好多个嵌套的IIF函数就是了。
缺点呢?当然有,首先冗余很大,即使没有填写对应的英文,一样要占用一个空间。其次,如果客户发神经,一下子选择了十几个语言,然后发现他并不需要,又想删除掉?那么我需要检查数据库的所有相关字段是否全部没有数据,才能决定可以删除这个语言并删除所有相关的字段。这是个问题。
XML字段
这种方式我就不画图了,很简单,还是只有一个字段Name,不过数据类型不是nvarchar,而是把定义成XML类型,这是SQLServer2005新增的类型,我们可以在此字段存储诸如下面这样的数据:
<items>
<item lng="" value="默认" />
<item lng="CHS" value="中文" />
<item lng="EN" value="English" />
</items>
那么在SQL中怎么输出对应的中文内容呢?很简单:
Select EmployeeId,Name.value(’(/items/item[@lng="CHS"]/@value)[1]’,’nvarchar(max)’) FROM Employees
很简单,我喜欢。
不过有人可能会说,其实没有xml类型前,我就已经使用nvarchar来实现了,使用一个自定义函数一样可以解决(使用诸如:/en/english /chs/中文的方式存储)。但是我认为字符串方式处理并不完美,主要表现在你必须自己小心处理特殊字符,否则很容易乱套。使用XML类型的话数据库会处理这些。另外,SQL Server对XML类型的查询有优化处理,比起SQL自定义函数运行的速度要快的多。而且,我相信,以后SQL Server对XML的支持会越来越好。
相关推荐:2010年全国计算机等级考试考试报考指南北京 | 天津 | 上海 | 江苏 | 山东 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
广东 | 河北 | 湖南 | 广西 | 河南 |
海南 | 湖北 | 四川 | 重庆 | 云南 |
贵州 | 西藏 | 新疆 | 陕西 | 山西 |
宁夏 | 甘肃 | 青海 | 辽宁 | 吉林 |
黑龙江 | 内蒙古 |