SQLServer存储多语言数据的几种方法
SQLServer存储多语言数据的几种方法
http://www.examda.com/ncre/three/db/fudao/20100111/102352311.html
本文概述了在数据库设计中，如何处理多国语言的问题，这里的多国语言是指诸如这样的业务：在ERP软件中，我们在填写客户名称时，除了需要填写客户的中文名称，还需要填写他的英文名称。 一般的，如果是普通的项目型软件，就比较简单了，你只需要设计出固定的 ChineseName和EnglishName字段就可以了。本文并不讨论这种形式，而是讨论在大型平台化的ERP软件中如何实现通用化的多语言存储和读取。
子表方式
第一种方式是建立一张子表，U9大概就是这个样子，你需要注意的是，每一个实体如果包含多语言字段，都会出现以_Trl为后缀的表。也许你会觉得麻烦，其实不然，这些都是平台在后台自动处理了，你仅仅需要标记这个字段是多语言字段就可以了。
从理论上来说，他的存储是最符合数据库设计原则的，不管你的系统使用多少语言，数据库结构是不变的。但是我总觉得查询起来SQL会比较复杂，虽然这事平台也会帮助你完成。我在想，如果我要一个多语言策略如何实现呢？多语言策略的例子：如果此字段没有对应的繁体中文，取简体中文，如果还没有，取默认的语言内容。那么在一个SQL中如何实现呢？
不管怎么样，至少我不喜欢这种。
多字段模式
恩？这是哪门子设计？和我上面讲的项目型设计不是一样吗？
数据结构是一样的，唯一的区别是通过ORM屏蔽了数据库的结构，在设计实体时，你仅仅设计了Name字段，其类型是“多语言类型”，然后在客户那里初始化时，客户可以决定采用多少种语言，然后ORM在后台自动添加这些列。
这是我希望的设计，因为他足够的简洁，任何人都可以非常方便的写出SQL语言。而且执行起来一定是最高效的。而且实现上面说的取值策略也很容易，只需要实现编排好多个嵌套的IIF函数就是了。
缺点呢？当然有，首先冗余很大，即使没有填写对应的英文，一样要占用一个空间。其次，如果客户发神经，一下子选择了十几个语言，然后发现他并不需要，又想删除掉？那么我需要检查数据库的所有相关字段是否全部没有数据，才能决定可以删除这个语言并删除所有相关的字段。这是个问题。
XML字段
这种方式我就不画图了，很简单，还是只有一个字段Name，不过数据类型不是nvarchar,而是把定义成XML类型，这是SQLServer2005新增的类型，我们可以在此字段存储诸如下面这样的数据：
<it
相关文档：
SQLServer和Oracle的常用函数对比
1.绝对值
S:select abs(-1) value
O:select abs(-1) value from dual
2.取整(大)
S:select ceiling(-1.001) value
O:select ceil(-1.001) value from dual
3.取整（小）
S:select floor(-1.001) value
O:select floor(-1.001) value from dual ......
CREATE TRIGGER trigger_name
ON { table | view }
[ WITH ENCRYPTION ]
{
{ { FOR ......
在数据库编程中，常会遇到要把数据库表信息导入Excel中， 有时则是把Excel内容导入数据库中。在这里，将介绍一种比较方便快捷的方式，也是比较普遍的。其实，这方法你并不陌生。原理很简单，把数据库表或Excel内容读取到dataset类型的变量中，再逐 ......
Author URL:http://www.cnblogs.com/xbf321/archive/2008/11/02/1325067.html
Microsoft URL:http://technet.microsoft.com/zh-cn/library/ms188001.aspx
摘要
1,EXEC的使用
2，sp_executesql的使用
MSSQL为我们提供了两种动态执行SQL语句的命令，分别是EXEC和sp_executesql;通� ......
今天编写了一个分页，在调试中出现了如下的错误:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Invalid call Statement method: {0}
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown Source)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown ......
