如何升级现已数据库为国际化的数据库，即全面采用Unicode。
请有国际化项目的朋友们，多多指点。
现在我需要将现有的db从非unicode升级到unicode，从而支持多国语言。
我想知道,如何升级和升级带来的影响:
1.磁盘存储的变化
2.性能的影响
3.索引的创建策略是否有所变化
4.对目前的复制分发模式是否有影响
5.是否操作系统需要调整
6.对目前的应用程序影响面
7.如何从非unicode到unicode升级
我简单进行了小结（可能不准确），请高手指点一下。
1.磁盘存储的变化
Unicode 与非 Unicode 在存储字符数据上的差别取决于非 Unicode 数据是否使用双字节字符集存储。
非Unicode字符，针对不同的语言占用的存储空间不一样：
（１）所有非东亚语言和泰语均用单字节存储非 Unicode 字符。
（２）许多其他亚洲语言的非 Unicode 代码页用双字节字符集 (DBCS) 指定字符存储。
SQL Server 2005 使用 UCS-2 编码方案来存储 Unicode 数据。在这一机制下，所有 Unicode 字符均用 2 个字节存储。
从非unicode到unicode存储空间的变化：
（１）非东亚语言和泰语从非 Unicode转为Unicode存储空间将是原来存储空间的两倍。
（２）许多亚洲语言，从非 Unicode转为Unicode存储空间将不变。
现有DB从非unicode升级到unicode的存储空间的变化：
现存储的字符有：英文和中文及数字。在非Unicode下，英文和数字都只占一个字节，而中文占两个字节。升级到Unicode（ucs-2）后，英文和中文及数字都将占两个字节。所以升级到Unicode（ucs-2）后，存储英文和数字的空间是原来的两陪，而存储中文的空间不会增加。
运行所下sql可得字符所占字节数：
select Datalength('x'),Datalength('5'),Datalength('完'),
Datalength(N'x') ,Datalength(N'5'),Datalength(N'完')
2.性能的影响
Unicode 数据对性能的影响由于多种因素而复杂化,一般通过以下几个方面来考虑对性能的影响，其影响程度无法量化，只有据特定的DB来测试 Unicode 存储机制是否严重影响性能。
（１）单纯由更多的存储空间带来的影响
使用 UCS-2 编码方案来存储 Unicode 数据，使得Unicode 字符均用 2 个字节存储。这样会降低磁盘的利用率，增加IO及占用更多的内存和CPU时间。如备份还原将需要更多的资源。
但总的来说对性能影响有限，因为公司DB现就存储了大量的双字节字符（如中文），而升级对这部份的后几乎没有什么影响。
（２）Unicode 排序规则和非 Unicode 排序规则之间的差别
SQL Server 使用 Unicode 排序规则来执行用 Windows 排序规则定义的非 Unicode 数据的字符串比较。这些规则比非 Unicode 排序规则复杂得多，它们更占用资源,但 Unicode 数据与 Windows 排序规则定义的非 Unicode 数据之间的性能差别通常却很小。
SQL Server 使用非 Unicode 排序规则的唯一情况是对于使用 SQL 排序规则定义的非 Unicode 数据。在这种情况下，排序和扫描通常比应用 Unicode 排序规则时快。Unicode 排序规则应用于使用 Windows 排序规则或 SQL 排序规则定义的所有 Unicode 数据。
（３）对排序性能的影响
由于 Unicode 数据是用双字节存储的，所以对大量 Unicode 数据排序可能比对非 Unicode 数据排序慢。但是，对亚洲 Unicode 字符排序比对特定代码页中的亚洲 DBCS 数据排序快，因为 DBCS 数据实际上是单字节和双字节宽度的混合，而 Unicode 字符具有固定的宽度。
（４）客户端与服务器之间的代码页转换对性能的影响
其他性能问题主要取决于如何在 SQL Server 实例和客户端之间转化编码机制。通常，客户端/服务器代码页转换对性能的影响是微乎其微的。
ODBC API 3.6 或更低版本以及 DB-Library API 都不能识别 Unicode。对于使用由这些 API 定义的数据访问方法的客户端，资源被用于隐式地将 Unicode 数据转换为客户端代码页。另外，当客户端代码页不能识别某些 Unicode 字符时，客户端面临着数据被损坏的风险。
从 SQL Server 7.0 附带的 Microsoft 数据访问组件 2.7 开始，以后的 ODBC 版本以及 OLE DB 和 ADO 均能识别 Unicode 并采用 UCS-2 编码机制。因此，如果应用程序支持 Unicode，即使确实需要使用来自 SQL Server 实例的 Unicode 数据，也不存在转换问题。如果客户端使用支持 Unicode 的 API，但 SQL Server 实例中的数据存储机制不是 Unicode，也不存在转换问题。但是，如果任何字符的码位无法映射到 SQL Server 代码页，就面临数据插入或更新操作失败的风险。
3.索引的创建策略是否有所变化
不必改变。原来的策略并没有基于创建索引的列为非Unicode（如varchar）或Unicode(nvarchar)。
4.对目前的复制分发模式是否有影响
复制分发的模式不受影响。
但需要注意的是：复制不包含对代理日志文件中统计信息的多语言支持。
5.是否操作系统需要调整
不需调整。因为sqlserver2005本身即支持Unicode。能支持sqlserver2000,2005的操作系统的都行，操作系统级无须特殊设置。
6.对目前的应用程序影响面
较大。要实现全面支持多国语言时。
应用程序中直接到数据库操作的ＭＳＳＱＬ中对unicode字符串的常量前必须加上Ｎ。
ＲＰＣ远程调用中必须将数据库端的变量（即编程对象中使用的变量）替换为unicode变量....
[最优解释]
1.磁盘存储的变化
简单的算法是, 字符型的总长度 * 2, 当然, 还要考虑因为长度修改导致一个数据页存放的记录数变化,这个比较影响磁盘存储. 另外, 索引页的数据存储空间开销也要考虑进去
2.性能的影响
主要考虑IO开销的增加
3.索引的创建策略是否有所变化
这个一般不会有什么变化
4.对目前的复制分发模式是否有影响
不会有影响(发布和订阅都改, 或者是改订阅的情况. 只改发布会有影响)
5.是否操作系统需要调整
不需要
6.对目前的应用程序影响面
有影响的是使用字符常量(加N前符符)
7.如何从非unicode到unicode升级
这个问题比较不好回答.
简单的回答就是你一个表一个表去改(managent studio 中的表设计器)
稍高级的做法是用 sp_msforeachtable 循环改所有表
最佳做法是自己写脚本来改, 当然这个脚本会很复杂, 至少你要做得到把要改的列相关的对象(索引/约束)等删除,改完字段类型后再建回去. 所以这个要看你对系统表的掌握程度
[其他解释]
強大
學習~~~
[其他解释]
強大
[其他解释]
连杰纶都学习了，我们能不学么
[其他解释]
ding ge
[其他解释]
ooooo
