子表方式第一种方式是建立一张子表,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
Select EmployeeId,Name.value(’(/items/item[@lng="CHS"]/@value)[1]’,’nvarchar(max)’) FROM Employees
很简单,我喜欢。
不过有人可能会说,其实没有xml类型前,我就已经使用nvarchar来实现了,使用一个自定义函数一样可以解决(使用诸如:/en/english /chs/中文的方式存储)。但是我认为字符串方式处理并不完美,主要表现在你必须自己小心处理特殊字符,否则很容易乱套。使用XML类型的话数据库会处理这些。另外,SQL Server对XML类型的查询有优化处理,比起SQL自定义函数运行的速度要快的多。
如果要实现PHP多语言不通数据库的话,可以通过将不同语言的数据存储在不同的数据库中来实现,每个语言的语言文件(如:zh_CN.php)和对应的数据库文件可以分别存放,并在调用数据库时使用对应的配置文件。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)