Microsoft SQL Server 2000의 국제 범용 기능
Michael Kaplan
Trigeminal Software, Inc.
요약: 이 기사는 Microsoft SQL Server 개발자에게 SQL Server 2000의 국제 범용 기능을 소개하고 유니코드, SQL Server의 국제 범용 데이터 형식, 구현에 관련된 주요 사안에 대해 설명합니다(57페이지/인쇄 페이지 기준).
목차
소개
유니코드의 정의 및 사용
SQL Server 2000의 데이터 형식
성능 및 저장 공간
시스템 테이블의 메타데이터 정보
데이터 정렬
서버와 클라이언트 간의 통신(코드 페이지 및 데이터 정렬 문제)
사용자 인터페이스의 다국어 데이터
SQL Server 데이터 액세스(데이터 액세스 방법)
다국어 Transact-SQL
SQL Server 2000의 로케일 지원
데이터 변환 서비스
다국어 데이터에 bcp 유틸리티 사용
Microsoft Search 서비스와 FTS
OLAP/계층적 데이터 처리
다국어 데이터에 SQL Server 2000의 XML 지원 사용
다른 데이터베이스 제품과의 상호 작용
결론
감사
필자 소개
소개
Microsoft® SQL Server™ 2000은 국제 범용 동작 및 환경을 지원하기 위한 강력한 기능들을 제공합니다. 광범위한 다국어 기능을 지원하는 SQL Server 2000은 선도적 데이터베이스 제품이자 응용 프로그램 플랫폼으로 인정받고 있습니다. 이 기사에서 이러한 기능의 전반적인 사용법에 대해 자세히 개괄합니다. 또한 단순히 기능을 나열하는 데 그치지 않고 다국어 요구 사항이 프로젝트의 각 부문에 어떤 영향을 미칠 수 있는지에 대해서도 설명합니다.
유니코드의 정의 및 사용
SQL Server 2000 다국어 지원은 유니코드 지원을 기반으로 제공됩니다. 유니코드는 전세계의 스크립트를 지원하도록 설계된 표준이며 플랫폼, 프로그램 또는 언어에 상관없이 모든 문자에 대해 고유한 코드 포인트를 제공합니다. 유니코드를 지원하는 프로그램은 어떤 언어로 된 데이터라도 처리할 수 있습니다. 유니코드 3.0은 최고 1,114,112자까지 처리할 수 있습니다.
유니코드는 모든 언어에 대한 단일 문자 집합 사용의 중요성을 깨달은 Unicode Consortium이라는 단체가 관리하는 산업 표준입니다. Microsoft도 Unicode Consortium의 회원입니다. 많은 업체들이 Microsoft와 같은 이유로 이 단체에 가입했습니다. 전세계적인 소프트웨어 솔루션을 개발할 때 다국어 데이터를 표현할 수 있는 기능은 매우 중요합니다. 다른 많은 업체와 개인들도 다국어 데이터 처리와 관련된 문제 및 기술을 익히기 위해 회원이 되고 있습니다.
현재 3.01 버전인 유니코드 표준은 ISO-10646과 같습니다. 이 국제 표준은 유니코드 1.1의 릴리스 직후부터 유니코드의 모든 코드 포인트와 일치합니다. 산업 표준과 국제 표준의 효율적인 결합을 통해 개별적 이해 관계를 뛰어넘어 모든 사람에게 단일 문자 집합을 제공한다는 두 표준의 공통 목표를 추구할 수 있게 되었습니다.
자세한 내용은 Unicode Consortium 웹 사이트 
를 참조하십시오.
인코딩
유니코드는 각 문자에 코드 포인트를 매핑합니다. 그러나 데이터가 실제로 메모리, 데이터베이스 또는 웹 페이지에서 어떻게 표현되는지에 대해서는 지정하지 않습니다. 이 때문에 유니코드 데이터의 실제 인코딩이 필요합니다. 유니코드에는 많은 인코딩이 사용됩니다. 이 절에서는 아래의 3가지 일반적인 인코딩에 대해 설명합니다.
- UCS-2
- UTF-16
- UTF-8
유니코드 및 유니코드를 저장할 수 있는 여러 가지 방법에 대한 이해를 돕기 위해 인코딩에 대해 잠시 살펴보겠습니다. 대부분의 경우 단순히 유니코드 데이터 형식을 선택하면 되므로 세부적인 이해가 필요하지는 않습니다. 그러나 아래와 같은 경우라면 인코딩에 대한 이해가 매우 중요합니다.
- 유니코드를 다른 방식으로 인코딩하는 응용 프로그램을 다룰 때
- Microsoft Windows® 이외의 플랫폼이나 다른 웹 서버로 데이터를 보내야 할 때
- 다른 인코딩으로 데이터를 보내거나 다른 인코딩에서 데이터를 가져와야 할 때
UCS-2
UCS-2는 Microsoft Windows NT® 4.0, Microsoft® SQL Server™ 버전 7.0 및 Microsoft SQL Server 2000에서 사용하는 기본 유니코드 인코딩입니다. UCS-2는 65,536개의 코드 포인트를 사용한 인코딩을 지원합니다. SQL Server 2000에서 유니코드로 저장되는 모든 정보가 이 인코딩으로 저장되며 이 인코딩은 사용되는 문자에 상관없이 모든 문자에 2바이트를 사용합니다. 따라서 라틴어 문자 "A"가 아래 문자들과 같은 방식으로 처리됩니다.
- 키릴 자모 Sha
- 히브리어 Lamed
- 타밀어 Rra
- 일본어 히라가나 E
문자마다 고유한 코드 포인트를 사용합니다. 위 문자들의 경우 각각 U+0041, U+0248, U+05DC, U+0BB1, U+3048이라는 코드 포인트를 사용하며 여기서 각각의 4자리 16진수는 UCS-2가 사용하는 2바이트를 나타냅니다.
운영 체제 수준에서는 각 바이트의 순서가 매우 중요할 수 있습니다. SQL Server는 Windows 플랫폼에서 동작하기 때문에 "작은 엔드 인"을 의미하는 Little Endian 인코딩 시스템을 사용합니다. 따라서 0x1234 같은 16진수 단어가 메모리에 0x34 0x12로 저장됩니다.
UTF-16
UTF-16은 Microsoft Windows 2000에서 사용하는 기본 유니코드 인코딩입니다. 유니코드 2.0이 발표되기 전에도 65,536자만으로는 모든 언어의 모든 문자에 대해 단일 코드 포인트를 지원한다는 유니코드의 목표가 불가능하다는 것을 알고 있었습니다. 중국어 같은 일부 언어의 경우 거의 사용되지 않는 문자들의 인코딩을 위해 매우 많은 문자가 필요합니다. 이러한 이유로 1,048,576개의 추가 문자를 처리하기 위한 대리자 범위 지원이 추가되었습니다. UTF-16은 원래 표준에 대한 이 확장을 완벽하게 지원하는 인코딩입니다. 대리자 범위에 대한 자세한 내용은 대리자의 정의 항목을 참조하십시오.
UTF-16에서도 코드 포인트마다 2바이트라는 표준을 따릅니다. 그러나 UTF-16의 특정 코드 포인트의 경우 바로 뒤에 다른 코드 포인트를 사용하여 문자를 정의합니다.
UCS-2처럼 UTF-16도 Windows에서 모든 것이 그렇듯 기본적으로 Little Endian 방식으로 저장됩니다.
중요 UCS-2는 대리자를 인식하지 못하지만 대리자가 포함된 데이터베이스의 실제 데이터를 손상하지 않고 이들을 정의되지 않은 별개의 두 문자로 처리합니다.
SQL Server 7.0과 SQL Server 2000은 대리자 쌍을 손실 없이 저장할 수 있지만 단일 문자가 아닌 정의되지 않은 2개의 유니코드 문자로 처리합니다. 이러한 응용 프로그램을 일반적으로 대리자 "중립적" 또는 대리자 "독립적" 응용 프로그램이라고 합니다. 여기서 "독립적"이란 데이터와 상호 작용할 수 있는 본질적인 기능이 없어도 데이터를 저장할 수 있다는 뜻입니다. 아직까지 대리자 "인식" 응용 프로그램은 흔하지 않습니다. 공식적으로 정의된 대리자 문자가 없기 때문입니다. Microsoft Word 2000, Microsoft Windows 2000 및 Microsoft Internet Explorer 버전 5.0 이상이 몇 안되는 대리자 인식 응용 프로그램입니다.
UTF-8
많은 ASCII 시스템 및 메일 서버처럼 8비트 인코딩이 필요한 바이트 기반 시스템에는 서로 다른 인코딩, 서로 다른 바이트 순서, 서로 다른 언어를 사용하는 온갖 종류의 컴퓨터가 있을 수 있습니다. UTF-8은 컴퓨터의 바이트 순서와 상관없이 유니코드 데이터를 처리하도록 만들어진 인코딩 방식입니다. SQL Server 2000은 UTF-8 형식으로 데이터를 저장하지 않습니다. 그러나 최소한 XML(Extensible Markup Language)을 지원한다는 면에서 UTF-8을 지원합니다. 자세한 내용은 이 기사 뒷부분의 다국어 데이터에 SQL Server 2000의 XML 지원 사용을 참조하십시오.
Oracle이나 Sybase SQL Server 같은 다른 많은 데이터베이스 시스템이 UTF-8 저장소를 사용하여 유니코드를 지원합니다. 서버의 구현 방식에 따라 데이터베이스 엔진이 이를 좀더 쉽게 구현할 수도 있습니다. 한번에 1바이트의 데이터를 처리하도록 만들어진 서버에서 기존의 모든 텍스트 관리 코드에는 큰 변화가 필요하지 않습니다. Windows 환경에서 UTF-8 저장소에는 아래와 같은 단점이 있습니다.
- COM(Component Object Model)이 API 및 인터페이스에서 UTF-16/UCS-2만 지원합니다. 따라서 UTF-8 형식으로 저장된 데이터의 경우 끊임없는 변환이 필요합니다. 이는 COM이 사용될 때만 그렇습니다. SQL Server 데이터베이스 엔진은 일반적으로 COM 인터페이스를 호출하지 않습니다.
- Windows NT 및 Windows 2000 커널은 모두 유니코드이며 각각 UCS-2와 UTF-16을 사용합니다. 다시 한번 강조하지만 UTF-8 저장소 형식은 많은 추가 변환을 요구합니다. COM 부분에서 이미 언급한 것처럼 이는 SQL Server 데이터베이스 엔진에서의 변환으로 끝나지 않고 많은 클라이언트쪽 작업에 영향을 미칩니다.
- 많은 문자열 작업 시 UTF-8의 속도가 떨어질 수 있습니다. 고정 너비 문자가 아니기 때문에 정렬, 비교는 물론 사실상 다른 모든 문자열 작업의 속도가 떨어질 수 있습니다.
- UTF-8은 주로 2바이트 이상을 필요로 하므로 늘어난 크기 때문에 디스크 및 메모리 공간이 많이 사용될 수 있습니다.
바이트 지향성이 강한 인터넷을 통한 통신의 경우 XML이 다른 무엇보다 중요한 표준이기 때문에 기본값으로 UTF-8을 사용한다는 것은 매우 합리적일 수 있습니다.
대리자의 정의
대리자 영역은 유니코드에서 1024개의 하위 대리자 값과 1024개의 상위 대리자 값이 포함된 U+D800부터 U+DFFF까지의 범위입니다. 상위 대리자 값과 하위 대리자 값을 조합하면 100만 개 이상의 문자를 사용할 수 있습니다. 대리자 쌍의 반쪽만 사용하는 것은 유효하지 않은 것으로 간주되며 언제나 상위 대리자 뒤에 하위 대리자가 와야 합니다. 따라서 대리자의 경우 DBCS(Double-Byte Character System) 문자를 검색해야 하는 다른 복잡한 규칙보다 쉽게 범위를 검사할 수 있습니다.
SQL Server 7.0이 릴리스되었을 때는 대리자가 없었습니다. SQL Server 2000이 릴리스될 당시 사용할 수 있었던 유일한 대리자 문자는 일반 텍스트의 언어 태그와 관련된 문자였습니다.
중요 앞에서 언급한 것처럼 어떤 데이터 손상이나 손실 없이 대리자를 저장할 수 있습니다. 그러나 이러한 데이터에 SQL Server의 문자열 처리 함수를 사용할 때는 매우 조심해야 합니다. 뿐만 아니라, 현재 Windows 2000은 대리자 문자에 대해 코드 포인트 정렬만 지원합니다.
SQL Server 2000이 릴리스된 후 ISO와 유니코드 표준 단체의 노력에 따라 40,000개의 CJKV(중국어, 일본어, 한국어, 베트남어) 표의문자를 포함한 더 많은 문자들이 대리자 범위에 추가되었습니다. 이러한 문자들은 주로 역사 및 고전 문학 자료에 사용되며 풍부한 CJKV 문학 작품을 인코딩하는 데 도움이 됩니다.
SQL Server 2000의 데이터 형식
데이터베이스의 가장 중요한 작업은 당연히 데이터의 저장입니다. 이 절에서는 국제 범용 데이터 저장을 위해 SQL Server 2000 데이터 형식을 사용하는 데 따른 몇 가지 문제에 대해 살펴봅니다.
유니코드 이외의 텍스트 형식: char, varchar, text
char, varchar 또는 text 데이터 형식으로 저장된 텍스트 데이터를 다룰 때는 단일 코드 페이지의 정보만 저장할 수 있다는 사실에 유의해야 합니다. 정확한 코드 페이지는 열 데이터 정렬에 따라 다릅니다. 열 수준 데이터 정렬이 없는 경우 데이터베이스 데이터 정렬이 사용됩니다. 특정 열에 사용되는 코드 페이지를 결정하려면 아래 예제처럼 COLLATIONPROPERTY 함수를 사용할 수 있습니다.
SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage') 936 SELECT COLLATIONPROPERTY('Latin1_General_CI_AI', 'CodePage') 1252 SELECT COLLATIONPROPERTY('Hindi_CI_AI_WS', 'CodePage') 0 마지막 예제의 경우, 그루지야어 또는 힌디어 등 많은 로케일이 "유니코드 전용" 데이터 정렬이므로 코드 페이지가 없다는 사실을 지적하기 위해 힌디어가 추가되었습니다. 이러한 데이터 정렬은 이러한 데이터 형식에 적합하지 않습니다.
이러한 열에 유니코드 데이터가 삽입되어야 할 때마다 WideCharToMultiByte API 및 데이터 정렬과 연결된 코드 페이지를 사용하여 열이 내부적으로 유니코드에서 변환됩니다. 주어진 코드 페이지로 나타낼 수 없는 문자는 언제나 물음표(?)로 바뀝니다. 일반적인 물음표가 변환 때문에 손상된 데이터를 나타내는 좋은 방법이 되는 것입니다. 또한 물음표는 유니코드 데이터 형식이 필요했다는 사실을 나타내기도 합니다. 유니코드 형식이 아닌 문자열 리터럴을 사용하는 경우 먼저 해당 데이터 정렬에서 나온 데이터베이스의 기본 코드 페이지를 사용하여 변환됩니다.
지원하고자 하는 문자 가운데 일부가 코드 페이지에 포함되어 있지 않을 때 데이터를 저장하려 하면 또 다른 문제가 발생할 수 있습니다. 아랍어 스크립트가 좋은 예입니다. 아랍어 스크립트는 발루치어, 베르베르어, 페르시아어, 카슈미르어, 카자흐어, 키르기스어, 쿠르드어, 파슈토어, 신디어, 위구르어, 우르두어 등을 포함한 광범위한 언어를 지원합니다. 이러한 모든 언어는 Windows 코드 페이지 1256의 바탕이 되는 아랍어에는 없는 추가 문자를 사용합니다. 따라서 이러한 추가 문자를 아랍어 데이터 정렬을 가진 유니코드 이외의 열에 저장하면 문자가 물음표로 변환됩니다. 많은 경우 Windows가 특정 코드 페이지를 "최적합" 코드 페이지로 간주하기 때문에 이 문제가 발생합니다. 이는 코드 페이지에 의존하여 모든 텍스트를 처리할 수 있다는 보장은 없지만 이용할 수 있는 최선의 방법이라는 뜻입니다.
유니코드 텍스트 형식: nchar, nvarchar, ntext
SQL-92 명세는 이러한 "N"(National - 국가 표준) 데이터 형식을 정의하지만 이들이 특별히 유니코드에 사용되어야 한다고 규정하지는 않습니다. 이러한 데이터 형식의 실제 정의는 데이터베이스 플랫폼 또는 개발자에 달려 있습니다. SQL Server 7.0 및 SQL Server 2000에서 이러한 데이터 형식은 UCS-2/UTF-16 유니코드와 같은 것으로 정의됩니다. 그러나 이는 Microsoft SQL Server에만 해당한다는 사실에 유의해야 합니다. Sybase SQL Server 같은 다른 데이터베이스 서버의 경우 "N" 데이터 형식이 특별히 유니코드를 의미하지는 않습니다.
힌디어나 타밀어 같은 복잡한 스크립트 저장소의 경우 데이터의 순서가 올바른 상태일 것으로 기대됩니다. 실제로 타밀어 등 많은 언어가 텍스트 렌더링 시 특정 문자들이 다시 정렬되도록 하며 따라서 사용자 인터페이스에 표시될 시각적 순서가 아닌 메모리에 저장되는 순서대로 텍스트의 논리적 순서를 만듭니다. 모든 인도어, 아랍어, 페르시아어, 히브리어 및 기타 많은 언어를 포함하여 모든 복잡한 스크립트 언어의 경우 데이터가 항상 올바른 논리적 순서로 저장되어야 합니다. 이러한 데이터의 실제 렌더링은 별개의 문제입니다. 이 기사 뒷부분의 사용자 인터페이스의 다국어 데이터를 참조하십시오.
"N" 열이 실제로 모든 언어 또는 언어 조합의 데이터를 지원할 수는 있지만 이 데이터의 실제 정렬은 단일 데이터 정렬만 가능합니다. 그 의미 및 결과에 대해서는 데이터 정렬 부분에서 자세히 설명합니다. 이 기사의 앞부분에서 언급한 코드 페이지 제약이 유니코드 열에는 전혀 적용되지 않습니다.
날짜/시간 형식: datetime, smalldatetime
실제 데이터 형식은 어떠한 실질적인 국제적 의미도 없으며 아래와 같은 정의를 가진 날짜/시간 값을 나타냅니다.
datetime
그레고리오 력 1753년 1월 1일부터 9999년 12월 31일까지 정확도 1/300초(3.33밀리초 또는 0.0033초)의 날짜 및 시간 데이터
smalldatetime
그레고리오 력 1900년 1월 1일부터 2079년 6월 6일까지 정확도 분 단위의 날짜 및 시간 데이터. 29.998초 이하의 smalldatetime 값은 가장 근사한 분으로 반내림되고 29.999초 이상의 값은 가장 근사한 분으로 반올림됩니다.
Microsoft SQL Server는 이 범위 밖의 데이터는 받아들이지 않습니다. 실제 데이터는 내부적으로 해당 날짜와 시간을 나타내는 두 정수(datetime은 4바이트 정수, smalldatetime은 2바이트 정수)로 저장됩니다. 실제 값이 로케일별 서식에 관한 실제 의미를 가지지 않기 때문에 개발자가 필요에 따라 이러한 변환을 정의할 수 있습니다.
SQL Server 2000은 개발자의 사용자 지정 솔루션에 의존하는 대신 서버에서 수행될 수 있는 많은 로케일별 변환을 지원합니다. 이러한 날짜 스타일은 CONVERT 함수를 통해 액세스할 수 있으며 이 함수는 아래 표에서 볼 수 있듯 데이터 형식, 표현식 및 선택적 스타일을 가집니다.
| 세기 포함 | 세기 없음 | 표준 | 입력(날짜/시간으로 변환) 출력(텍스트로 변환) |
| 0 또는 100 | - | 기본값 | mon dd yyyy hh:miAM(또는 PM) |
| 101 | 1 | 미국 | mm/dd/yy |
| 102 | 2 | ANSI | yy.mm.dd |
| 103 | 3 | 영국/프랑스 | dd/mm/yy |
| 104 | 4 | 독일 | dd.mm.yy |
| 105 | 5 | 이탈리아 | dd-mm-yy |
| 106 | 6 | - | dd mon yy |
| 107 | 7 | - | Mon dd, yy |
| 108 | 8 | - | hh:mm:ss |
| 9 또는 109 | - | 기본값 + 밀리초 | mon dd yyyy hh:mi:ss:mmmAM(또는 PM) |
| 110 | 10 | 미국 | mm-dd-yy |
| 111 | 11 | 일본 | yy/mm/dd |
| 112 | 12 | ISO | yymmdd |
| 13 또는 113 | - | 유럽 기본값 + 밀리초 | dd mon yyyy hh:mm:ss:mmm(24h) |
| 114 | 14 | - | hh:mi:ss:mmm(24h) |
| 20 또는 120 | - | ODBC canonical | yyyy-mm-dd hh:mi:ss(24h) |
| 21 또는 121 | - | ODBC canonical + 밀리초 | yyyy-mm-dd hh:mi:ss.mmm(24h) |
| 126 | - | ISO8601(공백 없음) | yyyy-mm-dd Thh:mm:ss:mmm |
| 130 | - | 쿠웨이트(회교) | dd mon yyyy hh:mi:ss:mmmAM |
| 131 | - | 쿠웨이트(회교) | dd/mm/yy hh:mi:ss:mmmAM |
아래 예제에서 CONVERT 함수가 어떻게 사용되는지 볼 수 있습니다.
SELECT CONVERT(char, GETDATE(), 100) AS [100] Aug 16 2000 11:50AM 같은 방식으로 문자열 데이터를 날짜 값으로 변환할 수 있습니다.
SELECT CONVERT(datetime, 'Aug 16 2000 11:50AM', 100) AS [100] 쿠웨이트 또는 회교 날짜처럼 스타일 130을 사용하는 날짜를 변환할 때 유니코드 변환에 코드 페이지 1256을 사용하는 아랍어 데이터 정렬이 아닌 경우 char 데이터 형식으로 변환하면 데이터가 손상될 수 있습니다. 아래 그림 1에서 이를 확인할 수 있습니다.
[그림 1] 날짜/시간 Transact-SQL 변환
미국 클라이언트 컴퓨터에서 char 데이터 형식을 사용하려 하면 아랍어 문자가 물음표로 변환되고 nchar 데이터 형식이 아랍어 문자로 렌더링됩니다. 이 특정 문자열은 SQL 쿼리 분석기의 SQL 표 형태 제한 때문에 아랍어 컴퓨터에서처럼 아직까지 클라이언트 컴퓨터에서 올바른 형식이 적용되지 않습니다. 아래 그림 2에서 실제 회교 날짜 문자열이 어떻게 나타나는지 볼 수 있습니다.
그림 2. 회교 날짜 문자열
이는 아랍어 같은 복잡한 스크립트의 경우 형상 규칙을 적용해야만 데이터가 올바르게 렌더링되기 때문입니다. 히브리어 같은 양방향(BIDI) 언어의 경우 모든 데이터의 방향이 바뀌어야 하며 그 효과는 아랍어에서 더욱 두드러집니다. 이는 주변 문자에 따라 문자의 실제 형태가 바뀔 수 있기 때문입니다. Windows 2000 또는 아랍어 사용이 가능한 이전 버전 Windows에서는 이 문제가 발생하지 않습니다.
뿐만 아니라, 양방향의 경우 반환되는 날짜 문자열 자체가 문제를 일으킬 수 있습니다. Internet Explorer 또는 Windows 2000 같은 응용 프로그램에 사용되는 양방향 텍스트 레이아웃 규칙 때문에 아래 그림 3처럼 날짜가 나타날 수 있기 때문입니다.
그림 3. 양방향 날짜 문자열 예제
이 오른쪽에서 왼쪽으로 표기(dd hh:mi:ss yyyy mon :)는 분명 기대되는 순서가 아닙니다. 아래 쿼리에서처럼 문자열 앞에 유니코드 제어 문자를 추가하여 이 문제를 쉽게 해결할 수 있지만 문제는 CONVERT 함수의 일반적 제약인 스타일 130에 있을 수 있습니다.
SELECT NCHAR(8207) + CONVERT(nchar, GETDATE(), 130) NCHAR 함수는 전달된 유니코드 코드 포인트를 기반으로 문자를 반환합니다. 코드 포인트 8207 또는 16진수 0x200F는 RLM(Right-to-Left Marker)이며 문자열이 올바르게 표시되도록 합니다.
성능 및 저장 공간
이상적으로, 모든 열은 유니코드 데이터 형식 가운데 하나로 정의됩니다. 그러나 다국어 데이터를 지원할 필요가 없을 때 이렇게 하면 저장 공간 및 속도와 관련된 문제가 발생할 수 있습니다.
저장 공간 문제
유니코드 데이터 형식에 필요한 실제 공간의 크기는 문자 당 2바이트이며 유니코드 이외의 데이터 형식에 필요한 공간은 모든 비DBCS 텍스트의 경우 1바이트, DBCS를 사용하는 아시아 언어의 경우 2바이트입니다. 따라서 데이터가 아시아어 코드 페이지에 있지 않으면 데이터를 저장하는 데 2배의 공간이 사용됩니다. 기존의 데이터베이스를 업그레이드하거나 새 프로젝트에 맞는 데이터 형식을 결정할 때 이점을 고려해야 합니다. 단일(비아시아) 코드 페이지의 열에만 데이터를 저장하는 경우 디스크 및 메모리의 공간을 절약하기 위해 유니코드를 사용하지 않을 수 있습니다.
속도 문제
속도 문제는 약간 복잡합니다. 몇 가지 속도 문제를 살펴보면 아래와 같습니다.
- Windows NT 또는 Windows 2000을 사용하는 경우 커널이 유니코드 데이터를 예상하기 때문에 데이터를 표시하거나 운영 체제 서비스를 사용하는 경우 등 많은 경우에 유니코드 이외의 열에 변환이 필요합니다.
- 많은 데이터를 로드하는 데 시간이 추가로 필요하다는 사실도 DBCS 데이터를 다룰 때 함께 고려해야 합니다.
- Windows 95 또는 Windows 98 클라이언트나 서버를 사용하는 경우 데이터 표시 같은 운영 체제 서비스가 필요할 때 많은 정보가 유니코드에서 변환될 수 있습니다.
- 여러 서버(이 기사 뒷부분의 서버와 클라이언트 간의 통신 참고), 데이터베이스 서버 제품 또는 기타 제품으로 작업하는 경우 얼마나 많은 변환이 이뤄지는가가 성능에 많은 영향을 미칠 수 있습니다.
- 아시아 언어를 다루는 경우 실제로 언어별 DBCS 코드 페이지를 사용하는 것보다 유니코드를 사용하는 것이 더 빠릅니다. 이는 DBCS 데이터가 고정 너비가 아니라 더블바이트와 싱글바이트 문자의 조합이기 때문입니다.
- 비아시아 언어를 다루는 경우 유니코드 이외의 데이터보다 유니코드 데이터를 정렬할 때 시간이 최고 30%까지 더 걸릴 수 있습니다. 이는 전세계의 데이터를 나타내기 위해 지불해야 할 한 가지 비용이라고 할 수 있습니다.
중요 현실적으로 성능 문제를 평가하려면 해당 상황에 대한 결정적인 데이터를 구해야 합니다.
시스템 테이블의 메타데이터 정보
SQL Server 2000의 시스템 테이블은 모든 데이터를 유니코드로 저장합니다. 따라서 데이터베이스와 열의 데이터 정렬이 다르기 때문에 발생할 수 있는 문제가 최소화됩니다. 한 서버의 서로 다른 데이터베이스가 유니코드와 유니코드 이외의 열 이름을 어떤 방식으로든 조합하여 가질 수 있으며 이를 다룰 다른 방법이 없습니다. 지금은 여러분이 단일 언어만 지원한다 하더라도 SQL Server는 앞으로 여러분이 요구할 모든 언어를 지원할 수 있어야 합니다.
데이터베이스 및 서버를 SQL Server 6.5 또는 그 이전 버전에서 변환할 때 변환되는 메타데이터에 대해 걱정할 수 있지만 그럴 필요가 없습니다. 유니코드로의 변환은 아주 간단합니다. 이전 버전 SQL Server는 서버 수준에서 정의된 한 가지 코드 페이지/데이터 정렬만 사용하기 때문입니다.
시스템 테이블의 개체 식별자 사용과 관련하여 한 가지 중요한 문제가 있습니다. SQL Server 2000은 유니코드 2.0의 문자 속성 정의를 사용하여 식별자에 유효한 문자 목록을 만듭니다. SQL Server 2000의 개발이 완료되었을 때 유니코드 3.0은 릴리스되지 않은 상태였습니다. 유니코드 2.0 문자 속성 정의에 정의되지 않은 다국어 문자와 관련된 문제를 피하려면 식별자를 대괄호([]) 또는 큰따옴표(")로 제한해야 합니다. 그러면 서버가 유효한 문자를 검사하지 않습니다.
데이터 정렬
모든 사람이 당연하게 생각하는 것 중 하나가 데이터 정렬과 관련하여 알파벳이 가장 기본적인 언어라고 생각하는 것입니다. 그리스어, 러시아어, 태국어, 일본어 등 서로 다른 문자 집합을 사용하는 언어를 아는 사람들도 있을 것입니다. 그러나 최소한 미국인들은 기본 언어라는 것이 있다면 그건 바로 알파벳이라고 생각하는 것 같습니다.
문제는 이런 생각이 잘못되었다는 것입니다. 스페인어를 아는 사용자들이 왜 문자 조합 "ch"를 "h" 뒤에 단일 문자로 정렬해야 한다고 생각하는지 이해하지는 못한다 하더라도 비영어권 언어의 정렬 순서가 다르다는 것은 알아야 합니다. 일반적으로, 정렬 같은 기본적인 요소에 문제가 있으면 최종 사용자들은 응용 프로그램을 불신하게 됩니다.
데이터 정렬이나 정렬 순서 그리고 문자열 정규화라는 기술을 통해 이 작업이 이뤄집니다. 이는 디자인의 문제가 아니므로 데이터베이스 개발자들에게 잘 알려진 "정규화"와는 다릅니다. 문자열 정규화란 두 문자열을 정렬할 수 있도록 이들을 비교하는 방법이라고 할 수 있습니다. 색인을 만들어 이 작업을 최적화할 수 있습니다.
유니코드가 아닌 열의 경우 데이터 정렬에 매우 중요한 둘째 의미가 있습니다. 즉, 데이터 정렬은 데이터의 코드 페이지, 따라서 어떤 문자를 나타낼 수 있는지 지정합니다. 유니코드 열 간에는 데이터를 문제 없이 이동할 수 있지만 유니코드가 아닌 열 간의 데이터 이동은 불가능합니다.
SQL Server 6.5 및 이전 버전의 데이터 정렬
SQL Server 6.5 및 그 이전 버전에서는 전체적으로 데이터 정렬에 의존하여 언어에 사용할 코드 페이지도 지정했습니다. 예를 들어, 다양한 라틴계 언어에는 여러 정렬 순서와 관련된 제한 사항이 있습니다. 또한 Latin-1을 사용하는 경우 서유럽어만 지원할 수 있었습니다. 이 때문에 단일 SQL Server 인스턴스에 나타낼 수 있는 로케일의 수, 즉 특정 지역에 사용되는 언어 수가 제한적이었습니다. 기본적인 문제들은 이후 버전 SQL Server의 유니코드가 아닌 필드 데이터 정렬에도 적용됩니다. 뿐만 아니라, 페르시아어 등 "최적합" 코드 페이지를 가진 언어에 대한 문제도(유니코드 이외의 텍스트 형식: char, varchar, text 참고) 적용될 수 있습니다.
SQL Server 7.0의 데이터 정렬
SQL Server 7.0은 서버마다 유니코드와 유니코드 이외의 데이터 정렬을 하나씩 가집니다. 유니코드 이외의 데이터 정렬은 코드 페이지 및 정렬 순서 ID에 대한 결정으로 이뤄집니다. 각 코드 페이지가 정렬을 둘 이상 지원할 수 있기 때문입니다. 예를 들어, 라틴계 언어는 일반적으로 대/소문자 구분 정렬과 구분 안함 정렬을 모두 지원하고 중국어 간체는 획수별 정렬과 발음별 정렬을 모두 지원합니다.
유니코드 데이터 정렬에서는 어떤 언어의 어떤 문자도 열에 포함될 수 있으며 데이터 정렬별 차이가 올바르게 처리될 수 있도록 개별 데이터 정렬을 사용할 수 있게 되어 있습니다. 이것이 "최적합" 문제에 대한 적절한 솔루션입니다. 예를 들어, 페르시아어 데이터를 일반적인 유니코드 데이터 정렬로 정렬하면 사용자들이 기대한 데이터를 얻기 때문입니다. 유니코드 데이터 정렬은 로케일 하나와 몇 개의 비교 스타일로 구성됩니다. 로케일은 일반적으로 국가나 문화 공유 지역의 이름을 따라 명명됩니다. 그리고 해당 지역의 표준에 따라 문자를 정렬합니다. 유니코드 데이터 정렬도 유니코드 표준에 포함된 모든 문자에 대한 정렬 순서를 제공하지만 지정된 로케일이 유니코드 데이터 정렬보다 우선합니다.
아래 표에 SQL Server 7.0에서 지원하는 고유 유니코드 데이터 정렬이 나와 있습니다. 목록에 없는 모든 로케일은 일반 유니코드 데이터 정렬을 사용합니다.
| 로케일 ID(LCID) | 설명 |
| 1033 | 일반 유니코드 |
| 33280 | 이진 순서 |
| 1027 | 카탈로니아어 |
| 197636 | 중국어 발음 기호(대만) |
| 2052 | 중국어 문장 부호 |
| 133124 | 중국어 획수 |
| 1028 | 중국어 획수(대만) |
| 1050 | 크로아티아어 |
| 1029 | 체코어 |
| 1043 | 네덜란드어 |
| 1061 | 에스토니아어 |
| 1036 | 프랑스어 |
| 66615 | 그루지야어(현대) |
| 1031 | 독일어 |
| 66567 | 독일어 전화 번호부 |
| 1038 | 헝가리어 |
| 66574 | 헝가리 전문 용어 |
| 1039 | 아이슬란드어 |
| 1040 | 이탈리아어 |
| 1041 | 일본어 |
| 66577 | 일본어 유니코드 |
| 1042 | 한국어 |
| 66578 | 한국어 유니코드 |
| 1062 | 라트비아어 |
| 1063 | 리투아니아어 |
| 1071 | 마케도니아어(마케도니아) |
| 1044 | 노르웨이어/덴마크어 |
| 1045 | 폴란드어 |
| 1046 | 포르투갈어 |
| 1048 | 루마니아어 |
| 1051 | 슬로바키아어 |
| 1060 | 슬로베니아어 |
| 1034 | 스페인어(정통) |
| 3082 | 스페인어(현대) |
| 1053 | 스웨덴어/핀란드어 |
| 1054 | 태국어 |
| 2057 | 영어(영국) |
| 1058 | 우크라이나어 |
| 1066 | 베트남어 |
이 목록에서 볼 수 있듯 모든 언어가 포함되는 것은 아닙니다. 모든 언어가 포함될 필요는 없으므로 이는 문제가 되지 않습니다. 예를 들어, 일반 유니코드 정렬 순서는 남아공 공용어, 알바니아어, 아랍어, 바스크어, 벨로루시어, 불가리아어, 영어, 페로스어, 페르시아어, 그루지야어(정통), 그리스어, 히브리어, 힌디어, 인도네시아어, 말레이어, 러시아어, 세르비아어, 스와힐리어 및 우르두어의 데이터는 물론 정렬도 올바르게 처리합니다. 그러나 표에 나와 있는 다른 언어들은 일반 유니코드 데이터 정렬과 하나 이상의 차이가 있습니다.
SQL Server 개발자들이 "정치적" 편견을 가지고 있지 않다는 것, 그리고 어떤 나라나 지역 사람들에게 다른 나라나 지역의 정렬 순서를 사용하도록 강요할 의도가 전혀 없다는 것을 알아야 합니다. 사실, 유고슬라비아의 세르비아 지역에 사는 사람이 크로아티아 정렬 순서를 사용하는 데 대해 걱정할 필요는 없습니다. 크로아티아어와 세르비아어 모두 같은 데이터 정렬을 사용하기 때문이며 이름은 임의적인 것일 뿐입니다. 다른 나라/지역의 고객들과 작업할 때는 이름 대신 숫자를 사용할 수 있습니다. 이름은 임의적인 설명일 뿐입니다. 가장 중요한 것은 데이터를 적절히 처리할 수 있는 데이터 정렬을 선택할 수 있다는 사실입니다.
SQL Server 7.0의 중요한 변화 중 하나가 운영 체제 독립적 문자열 비교 모델을 제공하는 것입니다. 따라서 Windows 95로부터 Windows 2000까지의 모든 운영 체제 간에 데이터 정렬의 일관성을 유지할 수 있습니다. Windows 2000이 자체 문자열 정규화를 위해 사용하는 코드와 같은 코드를 기반으로 하는 이 코드는 모든 컴퓨터에서 동일하도록 캡슐화됩니다. 이 변화 때문에 SQL Server는 소형 MSDE 설치로부터 대형 SQL Server 엔터프라이즈 버전에 이르기까지 더 이상 운영 체제에 의존하지 않고 국제 범용 기능을 지원합니다.
SQL Server 2000의 데이터 정렬
SQL Server 2000에서는 아래와 같은 이유로 데이터 정렬 모델이 변경되었습니다.
- 서로 다른 두 데이터 정렬을 요구함으로써 사용자들을 혼란스럽게 했습니다.
- 데이터 정렬을 지정할 수 있는 모든 새 장소를 처리하기 위해 좀더 유연한 모델이 필요했습니다.
- SQL Server 2000에서는 유니코드가 아닌 열의 코드 페이지를 처리하는 데도 데이터 정렬이 사용되므로 데이터 정렬이 더 많이 필요했습니다.
유니코드와 유니코드 이외의 정렬을 모두 처리하기 위해 일관성 있는 단일 모델이 개발되었습니다. 이 모델은 아래 목록에 표시된 언어를 지원합니다.
| SQL Server 2000의 데이터 정렬 | ||
| Albanian | Arabic | Chinese_PRC |
| Chinese_PRC_Stroke | Chinese_Taiwan_Bopomofo | Chinese_Taiwan_Stroke |
| Cyrillic_General | Croatian | Czech |
| Danish_Norwegian | Estonian | Finnish_Swedish |
| French | Georgian_Modern_sort | German_PhoneBook |
| Greek | Hebrew | Hindi |
| Hungarian | Hungarian_Technical | Icelandic |
| Japanese | Japanese_Unicode | Korean_Wansung |
| Korean_Wansung_Unicode | Latin1_General | Latvian |
| Lithuanian | Lithuanian_Classic | FYRO Macedonian |
| Modern_Spanish | Polish | Romanian |
| Slovak | Slovenian | Thai |
| Traditional_Spanish | Turkish | Ukrainian |
| Vietnamese |
이러한 각 데이터 정렬은 대/소문자 구분, 악센트 구분, 전자/반자 구분 또는 일본어 가나 구분이 있는지 여부를 정의하는 데 도움이 되는 일련의 접미사와 결합됩니다. 사용 가능한 정확한 접미사가 아래 표에 나와 있습니다. 이전 목록에 나온 40개의 언어 모두가 아래 표의 접미사 17개를 지원하므로 총 680개의 Windows 데이터 정렬이 가능합니다.
| 데이터 정렬의 접미사 | 의미 |
| _BIN | 이진 정렬 |
| _CI_AI | 대/소문자 구분 안함, 악센트 구분 안함, 일본어 가나 구분 안함, 전자/반자 구분 안함 |
| _CI_AI_WS | 대/소문자 구분 안함, 악센트 구분 안함, 일본어 가나 구분 안함, 전자/반자 구분 |
| _CI_AI_KS | 대/소문자 구분 안함, 악센트 구분 안함, 일본어 가나 구분, 전자/반자 구분 안함 |
| _CI_AI_KS_WS | 대/소문자 구분 안함, 악센트 구분 안함, 일본어 가나 구분, 전자/반자 구분 |
| _CI_AS | 대/소문자 구분 안함, 악센트 구분, 일본어 가나 구분 안함, 전자/반자 구분 안함 |
| _CI_AS_WS | 대/소문자 구분 안함, 악센트 구분, 일본어 가나 구분 안함, 전자/반자 구분 |
| _CI_AS_KS | 대/소문자 구분 안함, 악센트 구분, 일본어 가나 구분, 전자/반자 구분 안함 |
| _CI_AS_KS_WS | 대/소문자 구분 안함, 악센트 구분, 일본어 가나 구분, 전자/반자 구분 |
| _CS_AI | 대/소문자 구분, 악센트 구분 안함, 일본어 가나 구분 안함, 전자/반자 구분 안함 |
| _CS_AI_WS | 대/소문자 구분, 악센트 구분 안함, 일본어 가나 구분 안함, 전자/반자 구분 |
| _CS_AI_KS | 대/소문자 구분, 악센트 구분 안함, 일본어 가나 구분, 전자/반자 구분 안함 |
| _CS_AI_KS_WS | 대/소문자 구분, 악센트 구분 안함, 일본어 가나 구분, 전자/반자 구분 |
| _CS_AS | 대/소문자 구분, 악센트 구분, 일본어 가나 구분 안함, 전자/반자 구분 안함 |
| _CS_AS_WS | 대/소문자 구분, 악센트 구분, 일본어 가나 구분 안함, 전자/반자 구분 |
| _CS_AS_KS | 대/소문자 구분, 악센트 구분, 일본어 가나 구분, 전자/반자 구분 안함 |
| _CS_AS_KS_WS | 대/소문자 구분, 악센트 구분, 일본어 가나 구분, 전자/반자 구분 |
이러한 언어 이름은 임의적인 것이며 유니코드가 아닌 데이터의 고유한 각 지원 코드 페이지 및 모든 데이터의 정렬 순서를 잘 나타내도록 선택되었을 뿐입니다. 한 언어를 다른 코드 페이지로 완벽하게 나타낼 수 있거나 어떤 언어에 필요한 정렬 순서를 다른 정렬 순서로 지원할 수 있는 대부분의 경우 중복 지원이 필요하지 않으므로 목록에서 해당 언어를 "제거"했습니다. 일본어 가나 구분 및 전자/반자 구분의 기본 설정은 구분 안함이라는 사실을 염두에 두십시오.
이전 버전 SQL Server의 코드 페이지를 올바르게 지원하도록 이전 버전과 호환되는 많은 SQL 고유의 정렬 순서도 SQL Server 2000에 포함되었습니다. 이러한 SQL 고유의 정렬 순서가 아래 표에 나와 있습니다. 이들 중 많은 정렬 순서가 앞에서 설명한 다양한 접미사의 일부를 지원하지만 모든 접미사를 지원하지는 않습니다.
| SQL 고유의 정렬 순서 | ||
| SQL_1xCompat_CP850 | SQL_Estonian_CP1257 | SQL_Latin1_General_Pref_CP437 |
| SQL_AltDiction_CP1253 | SQL_Hungarian_CP1250 | SQL_Latin1_General_Pref_CP850 |
| SQL_AltDiction_CP850 | SQL_Icelandic_Pref_CP1 | SQL_Latvian_CP1257 |
| SQL_AltDiction_Pref_CP850 | SQL_Latin1_General_CP1 | SQL_Lithuanian_CP1257 |
| SQL_Croatian_CP1250 | SQL_Latin1_General_CP1250 | SQL_MixDiction_CP1253 |
| SQL_Czech_CP1250 | SQL_Latin1_General_CP1251 | SQL_Polish_CP1250 |
| SQL_Danish_Pref_CP1 | SQL_Latin1_General_CP1253 | SQL_Romanian_CP1250 |
| SQL_EBCDIC037_CP1 | SQL_Latin1_General_CP1254 | SQL_Scandinavian_CP850 |
| SQL_EBCDIC273_CP1 | SQL_Latin1_General_CP1255 | SQL_Scandinavian_Pref_CP850 |
| SQL_EBCDIC277_CP1 | SQL_Latin1_General_CP1256 | SQL_Slovak_CP1250 |
| SQL_EBCDIC278_CP1 | SQL_Latin1_General_CP1257 | SQL_Slovenian_CP1250 |
| SQL_EBCDIC280_CP1 | SQL_Latin1_General_CP437 | SQL_SwedishPhone_Pref_CP1 |
| SQL_EBCDIC284_CP1 | SQL_Latin1_General_CP850 | SQL_SwedishStd_Pref_CP1 |
| SQL_EBCDIC285_CP1 | SQL_Latin1_General_Pref_CP1 | SQL_Ukrainian_CP1251 |
| SQL_AltDiction_CP1253 | SQL_Hungarian_CP1250 | |
| SQL_Latin1_General_Pref_CP850 |
COLLATIONPROPERTY 함수를 사용하여 데이터 정렬에 대한 실제 정보를 검색할 수 있습니다. 앞에서 사용한 CodePage 값은 물론 Windows 로케일 ID를 반환하는(SQL 데이터 정렬에 대해 Null을 반환함) LCID 같은 다른 정보 유형도 보낼 수 있습니다. 이진 및 SQL 데이터 정렬 모두에 대해 Null을 반환하는 Windows ComparisonStyle을 지정할 수도 있습니다. 이 정보를 사용하여 모든 Windows 데이터 정렬에 대해 Windows 2000과 SQL Server 2000의 문자열 정규화 간에 등가물이 있는지 확인할 수 있습니다.
아래와 같이 fn_helpcollations() 함수를 사용하여 사용 가능한 모든 데이터 정렬을 반환할 수 있습니다.
SELECT * FROM ::fn_helpcollations() 이 쿼리는 SQL Server 2000에서 753개의 행을 반환합니다. 추가 데이터 정렬은 서비스 팩이나 이후 버전에 추가되지 않는 이상 추가할 수 없습니다.
데이터 정렬(Collation)이 데이터의 정렬(Sorting)을 지정하는 방법
데이터 정렬이 실제로 유니코드 데이터에서 어떻게 동작하는지 살펴볼 필요가 있습니다. 하나의 예외도 없이 SQL Server에서 유니코드 열에 정의된 모든 데이터 정렬은 정의된 모든 유니코드 문자를 정렬합니다. 데이터를 정렬할 수 있는 방법에 많은 차이가 있기 때문에 데이터 정렬에도 여러 종류가 있습니다. 그루지야어(현대)가 그 좋은 예입니다. 전통적인 그루지야어 텍스트 정렬 방식에서는 모든 문자를 특정 순서로 배치하지만 현대식 정렬에서는 거의 사용되지 않는 문자를 마지막에 배치하는 것이 일반적입니다. 아래 문자들이 이에 해당합니다.
- HE:
- HEI:
- WE:
- HAR:
따라서 그림 4와 5에 나온 것처럼 두 가지 방법을 사용하여 그루지야어 알파벳을 정렬할 수 있습니다.
[그림 4] 전통적인 그루지야어 알파벳 정렬 방식
[그림 5] 현대식 그루지야어 알파벳 정렬 방식
그러나 다른 모든 유니코드 데이터는 여전히 Latin1_General 데이터 정렬에 제공되는 정렬 방식대로 정렬됩니다. 사실 Georgian_Modern_Sort 데이터 정렬을 제외한 모든 데이터 정렬이 그루지야어를 전통적인 방식으로 정렬합니다. 다른 모든 데이터 정렬에도 같은 규칙이 적용되며 데이터 정렬마다 예외가 다를 뿐입니다.
여러 수준에서 지정되는 데이터 정렬
SQL Server 2000에서는 아래 수준에서 데이터 정렬을 지정할 수 있습니다.
- 서버 수준
- 데이터베이스 수준
- 열 수준
- 표현식
서버 수준에서 지정되는 데이터 정렬
지금까지 데이터 정렬이 주로 서버 수준에서 지정되었으며 많은 경우 서버 수준의 데이터 정렬만 설정하면 됩니다. 데이터 정렬을 명시적으로 데이터베이스 수준으로 설정하지 않는 한 서버에 만들어지는 모든 데이터베이스의 모든 데이터 정렬의 기본값은 서버 수준 데이터 정렬입니다. 데이터베이스에는 항상 데이터 정렬이 주어지기 때문에 데이터베이스가 만들어질 때를 제외하면 실제로 서버 수준 데이터 정렬이 참조될 일이 없습니다.
Program Files\Microsoft SQL Server\80\Tools\BINN 디렉터리의 master 다시 작성 유틸리티(RebuildM.exe)를 사용하면 설치 프로그램을 다시 실행하지 않아도 이 데이터 정렬을 변경할 수 있습니다. 자세한 내용은 SQL Server 2000의 SQL Server 온라인 설명서에서 "master 다시 작성 유틸리티" 항목을 참조하십시오.
예를 들어, 아래와 같이 Transact-SQL SERVERPROPERTY 함수를 사용하여 데이터 정렬에 대해 서버를 쿼리할 수도 있습니다.
SELECT CONVERT(char, SERVERPROPERTY('collation')) 데이터베이스 수준의 데이터 정렬
모든 데이터베이스는 정렬 순서가 데이터베이스 수준으로 설정된 고유한 데이터 정렬을 가질 수 있습니다. 아래 그림 6에 SQL Server 엔터프라이즈 관리자를 사용하여 데이터 정렬을 설정하는 방법이 나와 있습니다.
[그림 6] 엔터프라이즈 관리자에서 데이터 정렬 설정
Transact-SQL로도 데이터 정렬 순서를 설정할 수 있습니다. 예를 들어, 체코 정렬 순서로 대/소문자 및 악센트를 구분하는 새 데이터베이스를 만들려면 아래 문을 사용합니다.
USE master GO CREATE DATABASE Products ON ( NAME = products_dat, FILENAME = 'c:\program files\microsoft sql server\mssql\data\products.mdf' ) COLLATE Czech_CS_AS GO 흥미로운 사실은 ALTER DATABASE 문을 사용하여 기존 데이터베이스의 데이터 정렬도 변경할 수 있다는 것입니다. SQL Server 엔터프라이즈 관리자에서는 이 문을 사용할 수 없습니다. 예를 들어, 아래 문은 Products 데이터베이스의 데이터 정렬을 Czech_CS_AS에서 Czech_CI_AI로(대/소문자 및 악센트 구분을 구분 안함으로) 변경합니다.
ALTER DATABASE Products COLLATE Czech_CI_AI 데이터베이스의 데이터 정렬을 변경하기 전에 고려할 사항
데이터베이스의 데이터 정렬을 변경하려면 아래 조건이 모두 만족되어야 합니다.
- 다른 누구도 데이터베이스를 사용할 수 없어야 합니다.
- 어떤 스키마 바운드 개체도 데이터베이스 데이터 정렬로부터 독립적일 수 없어야 합니다. 유효한 스키마 바운드 개체에는 아래와 같은 개체가 있습니다.
- SCHEMABINDING로 만들어진 사용자 정의 함수 및 뷰
- 계산된 열
- CHECK 제약 조건
- 기본 데이터베이스 데이터 정렬에서 상속된 데이터 정렬을 사용하는 문자 열을 가진 테이블을 반환하는 테이블 반환 함수
- SCHEMABINDING로 만들어진 사용자 정의 함수 및 뷰
- 데이터베이스의 데이터 정렬을 변경해도 시스템 이름과의 중복이 발생하지 않습니다. 예를 들어, French_CI_AS에서 French_CS_AS로(대/소문자 구분 안함을 대/소문자 구분으로) 데이터 정렬을 변경하려 하는 경우를 생각할 수 있습니다. 이전 버전 SQL Server의 데이터 정렬에서는 Table1과 TABLE1이라는 두 테이블을 사용할 수 있었지만 SQL Server 2000의 데이터 정렬에서는 이들이 중복 테이블이 됩니다. 잠재적으로 이런 중복이 발생할 수 있는 개체는 아래와 같습니다.
- 프로시저, 테이블, 트리거 또는 뷰 같은 개체 이름
- 그룹, 역할 또는 사용자 같은 스키마 이름
- 시스템 및 사용자 정의 형식 같은 스칼라 형식 이름
- 전체 텍스트 카탈로그 이름
- 개체 안의 열 또는 매개 변수 이름
- 테이블 안의 인덱스 이름
- 프로시저, 테이블, 트리거 또는 뷰 같은 개체 이름
이러한 제약 조건은 모두 현실적인 조건이며 이들을 통해 데이터나 데이터베이스를 손상할 수 있는 작업을 피할 수 있습니다. 사실 규칙이 엄격하지 않다고 생각할 수도 있습니다. 그러나 text, varchar 또는 char 필드에 데이터가 있고 열에 명시적 데이터 정렬이 없는 경우 데이터베이스의 데이터 정렬을 변경하면 데이터의 인코딩 해석 방식이 바뀌며 결과적으로 모든 코드 페이지에 포함된 ASCII 범위를 벗어나는 모든 문자가 손상됩니다. 따라서 이런 식으로 모험을 하는 것보다, 이러한 열에 자체의 명시적 데이터 정렬이 사용되지 않는 한 유니코드 형식으로 되어 있지 않은 텍스트 데이터 열이 포함된 모든 데이터베이스의 데이터 정렬을 변경하지 말아야 합니다. 아래의 열 수준에서 지정되는 데이터 정렬을 참조하십시오.
또한 Transact-SQL DATABASEPROPERTYEX 함수를 사용하여 아래와 같이 데이터베이스의 데이터 정렬을 찾을 수도 있습니다.
SELECT CONVERT(char, DATABASEPROPERTYEX('pubs', 'collation')) 열 수준에서 지정되는 데이터 정렬
SQL Server 2000에서는 특정 열의 텍스트 데이터 정렬을 변경할 수 있습니다. 예를 들어, 암호 열에서 대/소문자를 구분해야 하는 경우 이 기능이 매우 유용합니다. 열마다 다른 언어를 사용하는 것도 유용할 수 있습니다. 예를 들어, 어떤 정렬 방식에서도 제외되지 않도록 고객 이름은 Latin1_General을 사용하여 유니코드로 만들고 제품 라인에는 그리스어가 맞기 때문에 항상 그리스어를 사용해야 할 수 있습니다. 아래 그림 7은 SQL Server 엔터프라이즈 관리자를 사용한 테이블 디자인 단계의 데이터 정렬 지정을 나타낸 것입니다.
[그림 7] 엔터프라이즈 관리자를 사용한 테이블 디자인 단계의 데이터 정렬 지정
"..." 단추를 클릭하면 아래 그림과 같은 대화 상자가 나타납니다. 이 대화 상자에서(그림 8) 데이터 정렬을 선택할 수 있습니다.
[그림 8] 데이터 정렬 대화 상자
Transact-SQL을 사용하여 열 수준 데이터 정렬을 설정할 수도 있습니다. CREATE TABLE 문에서 열 정의에 COLLATE 절을 추가하기만 하면 됩니다. 아래 예제에서는 일자리 설명에 대한 데이터 정렬이 아랍어(대/소문자 및 악센트, 일본어 가나 구분 안함)로 설정되어 있습니다.
CREATE TABLE jobs ( job_id smallint IDENTITY(1,1) PRIMARY KEY CLUSTERED, job_desc varchar(50) COLLATE Arabic_CI_AI_KS NOT NULL DEFAULT 'New Position - title not formalized yet', ) ALTER TABLE 문을 사용하여 열 수준에서(ntext 또는 text 열 제외) 새 데이터 형식으로 데이터 정렬을 변경할 수 있습니다. 그러나 ntext 열의 데이터 정렬은 SQL Server 엔터프라이즈 관리자를 사용하여 변경할 수 있습니다. 이는 SQL Server 엔터프라이즈 관리자가 temp 테이블을 만들고, 데이터를 새 temp 테이블로 옮기고, 이전 테이블을 제거하고, 새 데이터 정렬을 가진 새 테이블을 만든 다음 데이터를 다시 새 테이블로 복사하기 때문입니다.
표현식에 지정되는 데이터 정렬
여러 나라 사람에게 데이터를 보여주고 로케일에 맞는 정렬을 사용해야 하는 경우가 종종 있을 것입니다. SQL Server 2000에서는 표현식에 데이터 정렬을 지정할 수 있습니다. 이 유용한 새 기능을 통해 언어별 ORDER BY 절이 만들어지도록 특별한 방식으로 정렬할 수 있습니다.
예를 들어, 아래 쿼리는 Customers 테이블을 성과 이름에 따라 정렬합니다. 문자 Y가 문자 뒤에 어떻게 정렬되는지에 대한 규칙이 매우 분명히 드러나기 때문에 리투아니아어 정렬 순서를 사용하면 데이터 정렬의 차이를 쉽게 확인할 수 있습니다.
SELECT * FROM tblCustomers ORDER BY LastName COLLATE Lithuanian_AI_CI, FirstName COLLATE Lithuanian_AI_CI SQL Server 2000의 SQL Server 온라인 설명서에서 아래와 같은 일반 비교 관련 예제를 참조할 수도 있습니다.
SELECT * FROM Table1 WHERE Field1 = Field2 COLLATE Turkish_ci_ai Table1에 명시적 열 수준 데이터 정렬이 없으면 두 열 모두 터키어 정렬 순서와 비교됩니다. 그 이유에 대한 자세한 내용은 이 기사 뒷부분의 데이터 정렬의 우선 순위 규칙을 참조하십시오.
COLLATE 키워드
COLLATE 키워드는 아래와 같은 구문에 사용됩니다.
COLLATE [<Windows_Collation_name>|<SQL_Collation_Name] 데이터 정렬 이름을 선택하는 것이 어려울 수도 있습니다. 키워드는 데이터베이스 수준, 열 수준 또는 표현식에 지정할 수 있습니다. 대체적으로 ntext, nvarchar 또는 nchar 등 유니코드 필드가 아닌 경우 언제나 데이터 정렬을 코드 페이지로 변환하는 초기 프로세스가 사용됩니다.
아래와 같은 두 종류의 데이터 정렬이 있습니다.
Windows 데이터 정렬
Windows가 정의하는 데이터 정렬입니다. 대/소문자 구분, 악센트 구분, 일본어 가나 구분, 전자/반자 구분 등 모든 옵션을 사용할 수 있을 뿐만 아니라 이진 정렬도 정의할 수 있습니다.
SQL 데이터 정렬
SQL Server가 레거시 이유 때문에 정의하는 데이터 정렬입니다. 이러한 정렬을 구성하기 위한 전체 옵션을 사용할 수 없습니다.
일반적으로 가능한 한 Windows 데이터 정렬을 사용해야 합니다. 아래 그림 9는 정렬 규칙이 어떻게 변경될 수 있는지에 대한 간단한 예를 나타낸 것입니다. 이 예제에서는 pubs 데이터베이스가 사용됩니다. Y가 I와 J 사이에 오느냐 X와 Z 사이에 오느냐는 리투아니아어 데이터 정렬이 사용되느냐 그렇지 않느냐에 달려 있습니다. 리투아니아어 데이터 정렬은 쿼리의 항목이 정렬되는 방식에 분명한 영향을 미칩니다.
[그림 9] 정렬에 영향을 미치는 데이터 정렬 예제
데이터 정렬의 우선 순위 규칙
SQL Server 2000에서는 서버, 데이터베이스, 열 및 표현식에 데이터 정렬을 지정할 수 있습니다. 이들이 어떻게 상호 작용하는지 살펴보겠습니다.
상호 작용은 약간의 간단한 규칙을 통해 이뤄집니다. 또한 처음에는 혼란스러워 보이겠지만 이 규칙은 분명 필요합니다. 아래 표는 A와 B가 비교의 각기 다른 두 부분으로 상호 작용하는 모습을 보여줍니다.
| 명시적 B | 암시적 B | 기본값 | 데이터 정렬 없음 | |
| 명시적 A | 런타임 오류 | 명시적 A | 명시적 A | 명시적 A |
| 암시적 A | 명시적 B | 데이터 정렬 없음 | 암시적 A | 데이터 정렬 없음 |
| 기본값 | 명시적 B | 암시적 B | 기본값 | 데이터 정렬 없음 |
| 데이터 정렬 없음 | 명시적 B | 데이터 정렬 없음 | 데이터 정렬 없음 | 데이터 정렬 없음 |
이 표에 사용되는 용어의 정의는 아래와 같습니다.
명시적 A/명시적 B
주어진 표현식에 대해 명시적으로 데이터 정렬이 정의됩니다.
암시적 A/암시적 B
열 수준에서 데이터 정렬이 정의됩니다.
기본값
데이터베이스 수준 데이터 정렬이 사용됩니다.
데이터 정렬 없음
두 연산자 간에 충돌이 있기 때문에 데이터 정렬 없이 표현식이 처리됩니다.
여기에서 볼 수 있듯 SQL Server가 표현식을 처리할 수 없는 유일한 경우는 서로 충돌하는 두 데이터 정렬이 명시적으로 정의되거나 비교하려는 두 항목이 비교를 위한 공통 분모를 가지고 있지 않을 때뿐입니다. 그러나 이들은 이유 없는 제약이 아니라 이해할 만한 규칙입니다. SQL Server가 필요로 하는 것은 비교를 위한 약간의 공통 분모일 뿐입니다.
예를 들어, 아래의 Transact-SQL 문을 사용하여 테이블을 만드는 경우를 생각할 수 있습니다.
CREATE TABLE TestTab ( id int, GreekCol nvarchar(10) COLLATE greek_ci_as, LatinCol nvarchar(10) COLLATE latin1_general_cs_as ) INSERT TestTab VALUES (1, N'A', N'a') GO 이 문은 대/소문자를 구분하지 않고 악센트를 구분하는 그리스어 데이터 정렬을 사용하는 열과 대/소문자 및 악센트를 구분하는 General Latin1 데이터 정렬을 사용하는 열을 가진 테이블을 만듭니다.
아래와 같이 이 둘을 명시적으로 비교하는 쿼리를 사용할 수 있습니다.
SELECT * FROM TestTab WHERE GreekCol = LatinCol 그러나 이렇게 하면 오류가 발생합니다.
Msg 446, Level 16, State 9, Server V-MICHKA3, Line 1 Cannot resolve collation conflict for equal to operation. 이 오류가 발생하는 이유는 서버가 각기 다른 데이터 정렬을 가진 두 텍스트 세그먼트를 비교할 수 없기 때문입니다. 그러나 COLLATE 키워드를 사용하여 이들이 호환되도록 하는 표현식을 명시적으로 작성하면 아래와 같이 쿼리가 동작합니다.
SELECT * FROM TestTab WHERE GreekCol = LatinCol COLLATE greek_ci_as 일반적으로 LatinCol은 대/소문자 구분 데이터 정렬을 사용하지만 표현식의 대/소문자 비구분 데이터 정렬이 이 정렬 방식에 우선하여 대문자 'A'와 소문자 'a'가 똑같이 다뤄질 수 있도록 합니다.
COLLATE 키워드의 제한
COLLATE 키워드와 그 모든 관련 기능은 현재 필적할 만한 다른 엔터프라이즈 데이터베이스 제품을 찾을 수 없을 정도로 매우 뛰어납니다. 그러나 아래에 설명된 것처럼 약간의 제한은 있습니다. 그러나 또한 이러한 제한에는 모두 해결 방법이 있습니다. 이러한 제한에 대해 설명하는 이유는 사용자가 직접적으로 어떤 방법을 사용할 수 있고 어디에 추가 작업이 필요한지 이해하도록 하기 위해서입니다.
전체 데이터 정렬 목록을 반환하지 않음
fn_helpcollations 함수(이 기사 앞부분의 열 수준에서 지정되는 데이터 정렬에 나오는 그림 참고)는 전체 데이터 정렬 목록을 반환합니다. 그러나 이 기사 앞부분의 데이터베이스 수준의 데이터 정렬에 나오는 대화 상자에서 볼 수 있듯 SQL Server는 알바니아어 같은 한 로케일을 확실히 나열하고 나머지 플래그는 옵션으로 제공하며 마지막에 전체 문자열을 반환할 수 있습니다. 이 기능을 위한 사용자 인터페이스를 제공하려면 직접 약간의 추가 작업을 해야 합니다.
열 수준에서 데이터 정렬을 정의할 때의 문제
데이터베이스에는 Latin1_General을 사용하고 열에는 그리스어를 사용하는 등 데이터베이스와 열에 각기 다른 정렬 순서를 사용해야 하는 경우가 얼마나 자주 있습니까? 가끔은 이런 경우도 있겠지만 다른 경우, 즉 데이터베이스의 데이터가 단일 데이터 정렬을 사용하지 않는 경우 이는 둘 이상의 데이터 정렬에 따라 정렬해야 하는 다국어 데이터일 것입니다. 색인화가 모두 가능한 복수의 데이터 정렬을 정의할 수 있으므로 그리스어 데이터 정렬을 지정하여 그리스어 데이터에 액세스할 수 있고 이 쿼리를 색인화된 검색으로 만들 수 있습니다.
"쿼리를 색인화된 검색으로 만들 수 있다"는 것이 가장 중요합니다. 앞에서 소개한 예제에서처럼 쿼리의 ORDER BY 절에 COLLATE 표현식을 사용하면 기능성을 얻을 수 있지만 이는 색인화된 정렬이 아니기 때문에 대량의 데이터 집합을 처리할 때 속도가 떨어집니다. 말 그대로, 열 수준 데이터 정렬이란 열의 데이터가 단일 언어 데이터가 아닌 경우 또는 열마다 각기 다른 언어를 저장하기 위해 데이터베이스를 비정규화하는 경우에만 의미가 있습니다.
LCID 및 데이터 정렬
Windows는 로케일 ID(LCID)를 사용하여 정렬을 정의합니다. 결과에 형식을 적용하는 단계라면 LCID가 이미 준비되어 있을 것입니다. 또는 1024를 지정하거나 Microsoft Visual Basic®의 형식 지정 함수를 사용하여 기본 LCID를 지정함으로써 원하는 작업을 수행할 수 있습니다. 사실 Web 기반 ASP 응용 프로그램에서 이 작업을 수행하는 경우 Microsoft VBScript(Visual Basic Scripting Edition)의 SetLocale 함수를 사용하여 원하는 로케일의 날짜/시간, 숫자 및 통화 형식의 기본 설정이 사용되도록 형식을 변경할 수 있습니다. 불행히도 둘을 매핑할 수 있는 방법은 없습니다. 데이터 정렬에서 LCID를 얻을 수는 있지만 LCID와 데이터 정렬의 다대일 매핑 때문에 LCID에서 데이터 정렬을 얻을 수는 없습니다.
이 제한이 불편한 이유가 무엇이겠습니까? 각기 다른 나라의 사용자들이 방문하여 제품 정보를 검색하는 다국어 웹 사이트를 운영한다고 가정해 보겠습니다. 여러분은 이미 날짜 및 통화 값을 올바르게 표시하기 위해 Session.LCID 속성을 사용하여 사용자 브라우저의 HTTP_ACCEPT_LANGUAGE 변수를 LCID로 매핑했을 것이며 가용성 측면에서 사용자의 로케일을 사용한 정렬이 올바른 옵션이라고 생각할 것입니다.
자체적인 매핑 함수를 사용하여 이 문제를 해결하는 방법에 대한 자세한 내용은 SQL Server 2000의 SQL Server 온라인 설명서에서 "Windows 데이터 정렬 지정자" 항목을 참조하십시오.
ISO 문자열 및 데이터 정렬
아래와 같은 스크립트를 사용하여 VBScript에서 HTTP_ACCEPT_LANGUAGE 변수를 얻을 수 있습니다.
Dim stLang stLang = Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") 로케일 정보와 관련하여 이 값이 많은 웹 개발자들이 가지게 될 유일한 값이라는 사실을 인식했기 때문에 VBScript의 SetLocale 함수는 LCID 값뿐만 아니라 이 값도 직접적으로 받아들이도록 만들어졌습니다. 이는 값을 LCID에 매핑하는 중간 단계를 거칠 필요가 없다는 뜻입니다. SQL Server 2000은 "en-us"(English-United States) 같은 문자열을 받아들이지 않으며 이를 Latin1_General 데이터 정렬 또는 "vi"(베트남어)에 적절히 매핑하거나 베트남어 데이터 정렬에 매핑하지 않기 때문에 이들 모두를 직접 매핑해야 합니다.
사용자 정의 데이터 정렬을 정의하는 방법
수많은 데이터 정렬 옵션을 본 후 많은 개발자들이 주로 하는 질문 중 하나가 사용자 정의 데이터 정렬을 어떻게 정의할 수 있느냐는 것입니다. 대답은 불가능하다는 것입니다. Windows 2000에 데이터 정렬이 추가되지 않는 한 SQL Server 2000에도 추가될 수 없습니다. 이는 데이터 정렬이란 말 그대로 유니코드 표준에 정의된 모든 문자의 정렬 방법을 정의하기 위해 만들어졌고 데이터 정렬을 만들 수 있도록 허용하는 사용자 인터페이스가 없기 때문입니다.
참고 새 SQL Server 데이터 정렬은 모두 Windows의 정보에서 나옵니다. 이들을 Windows 데이터 정렬이라고 하는 이유가 여기에 있습니다.
서버와 클라이언트 간의 통신(코드 페이지 및 데이터 정렬 문제)
SQL Server 작업 시, 서버가 있는 컴퓨터에서 모든 작업을 수행하고 SQL 쿼리 분석기 또는 SQL Server 엔터프라이즈 관리자 같은 SQL Server 도구만 사용하는 경우도 드물게 있습니다. 그러나 대부분의 경우 서버는 다른 서버나 클라이언트와 상호 작용하고 하나 이상의 데이터 액세스 표준을 사용합니다. 이러한 사안이 SQL Server 2000에서는 어떻게 다뤄지는지 살펴보겠습니다. 여기서는 SQL Server와 통신하는 모든 것을 클라이언트라 하며 기본적으로 아래와 같은 두 종류의 클라이언트가 있습니다.
- 유니코드 클라이언트: OLE DB 및 ODBC 버전 3.7 이상
- 유니코드 이외의 클라이언트: ODBC 버전 3.7 이하, DB-Library
유니코드 이외의 데이터와 관련하여 한 가지 주목할 부분은 ODBC가 사용될 때 유니코드 간에 또는 코드 페이지 간에 데이터가 변환되는 방식입니다. SQL_COPT_SS_TRANSLATE 특성을 SQLSetConnectAttr로 보낼 때 아래의 두 설정을 사용할 수 있습니다.
- SQL_XL_OFF
클라이언트와 서버 간에 교환되는 문자 데이터에 대해 드라이버가 코드 페이지를 변환하지 않습니다.
- SQL_XL_ON
클라이언트와 서버 간에 교환되는 문자 데이터에 대해 드라이버가 코드 페이지를 변환합니다. 드라이버가 자동으로 문자 변환을 구성하고 서버에 설치된 코드 페이지와 클라이언트가 사용하는 코드 페이지를 확인합니다.
기본적으로 SQL_XL_ON 특성이 사용됩니다. 또한 SQLServer 개체의 SQL-DMO TranslateChar 메서드를 사용하여 설정할 수도 있습니다. 일반적으로 유니코드 이외의 데이터를 다룰 때는 이 기본값으로 원하는 동작(auto_translate를 켜는 것)을 얻을 수 있습니다.
가능한 클라이언트/서버 연결 시나리오에 대해 다른 몇 가지 사안과 함께 다음 주제 항목에서 설명합니다.
유니코드 서버와 클라이언트
이 구성 형태가 이상적입니다. 프로세스 전체에 걸쳐 데이터를 유니코드로 유지하면 최상의 성능을 얻을 수 있고 검색된 데이터의 손상을 막을 수 있습니다. ADO와 OLE DB가 이 경우에 해당됩니다.
유니코드 서버와 하나 이상의 유니코드가 아닌 클라이언트
이 구성 형태의 경우 데이터를 저장하는 데는 아무 문제가 없지만 데이터를 클라이언트로 가져와 사용할 때는 분명히 심각한 제약이 있습니다. 어느 시점이 되면 유니코드 데이터를 변환하기 위해 클라이언트 코드 페이지를 사용해야 합니다.
DB-Library를 사용하는 컴퓨터에서 SQL Server 2000 데이터베이스에 연결할 때 데이터 층에서 이런 일이 발생합니다. DB-Library는 C 응용 프로그램이 SQL Server에 액세스할 수 있도록 하는 호출 수준 인터페이스입니다. DB-Library가 SQL Server 6.5 이후 크게 업그레이드되지 않았다는 사실을 떠올리면 DB-Library를 사용하는 클라이언트가 마주칠 수 있는 제한이 무엇인지 분명하게 드러납니다. 데이터가 하나의 코드 페이지, 즉 시스템의 기본 OEM 코드 페이지만 사용할 수 있습니다. 또한 로케일 정보가 클라이언트 시스템의 로케일 설정을 따르도록 할 것인지 여부를 선택할 수 있습니다. 아래 그림 10에서 볼 수 있듯 SQL Server 클라이언트 네트워크 유틸리티의 DB 라이브러리 옵션 탭에서 DB-Library의 정보 변환 방법에 대해 두 가지 옵션을 사용할 수 있습니다. 기본적으로 두 옵션 모두 선택되어 있습니다.
[그림 10] 기본 DB 라이브러리 옵션
다른 코드 페이지의 데이터를 처리할 수 없기 때문에 SQL Server의 데이터 하위 집합만 다루면 되는 레거시 시스템에서만 DB-Library가 데이터 층으로서 의미가 있습니다. 이는 이를 이미 사용하고 있는 개발자들이 응용 프로그램을 다시 작성하는 일이 발생하지 않도록 하기 위한 기술이지만 다국어 데이터를 지원해야 하는 경우 다시 작성하는 것도 좋은 방법일 수 있습니다.
유니코드가 아닌 클라이언트의 다른 예로는 Microsoft Access 97처럼 유니코드 사용이 가능하지 않은 프로그램이 있습니다. Access 데이터베이스를 SQL Server 2000 데이터베이스에 연결할 수는 있지만 몇 가지 제한 사항이 있다는 것을 알아야 합니다. 예를 들어, 미국 영어를 사용하는 컴퓨터에서 일본어 테이블 이름을 가진 데이터베이스에 연결하면 테이블 이름이 물음표로 변환되었다는 대화 상자가 나타날 것입니다. 아래 그림 11은 이런 대화 상자의 예를 나타낸 것입니다.
[그림 11] Access 97에서 물음표로 변환된 테이블 이름
이 문제가 나타나는 이유는 간단합니다. Access 97은 3.7 이전의 ODBC 버전을 사용하므로 기본 시스템 코드 페이지를 사용하여 데이터가 유니코드에서 ANSI로 변환됩니다. 이후 버전 ODBC를 설치해도 Access 97의 Jet 3.5는 같은 방식으로 변환을 수행합니다. 미국 영어를 사용하는 컴퓨터의 코드 페이지 1252에 일본어 문자가 없기 때문에 물음표로 변환되는 것입니다.
이러한 테이블에는 연결할 수 없습니다. 연결을 시도하면 그림 12의 오류 메시지가 나타납니다.
[그림 12] Microsoft Access 오류 메시지
이 오류 메시지가 나타나는 이유 또한 간단합니다. 일단 데이터가 잘못된 코드 페이지로 변환되고 물음표로 바뀌면 원래 상태로 되돌릴 수 있는 방법이 없습니다. 따라서 Jet 및 ODBC가 dbo.????라는 테이블에 연결해도 이런 테이블은 존재하지 않기 때문에 성공하지 못합니다. 해당 코드 페이지에 없는 모든 데이터에서 이런 문제가 발생합니다.
비슷한 문제가 테이블 안의 데이터에서도 발생합니다. 예를 들어, 한국어 데이터가 포함된 테이블에서 Access 같은 유니코드가 아닌 클라이언트의 데이터는 물음표로 표시됩니다. 그림 13은 이를 나타낸 것입니다.
[그림 13] 유니코드가 아닌 클라이언트 데이터베이스의 물음표
이 세 클라이언트(DB-Library, ODBC, Jet 3.5)에서, 기본 시스템 코드 페이지로 변환하는 방법을 제외하고 유니코드를 이해하지 못하는 구성 요소는 이런 종류의 다국어 데이터를 처리할 수 없습니다. 이런 클라이언트는 기본 시스템 코드 페이지에 포함될 수 있는 데이터만 사용할 수 있습니다.
유니코드가 아닌 서버와 유니코드 클라이언트
다국어 데이터에는 적합하지 않은 구성 형태입니다. 서버에 이러한 데이터를 유지할 수 없기 때문입니다. 그러나 최소한 데이터만큼은 올바르게 표시됩니다. 이 구성 역시 앞에서 설명한 시나리오의 모든 제한을 가지고 있지만 무효한 변환 때문에 받은 데이터가 손상될 위험은 없습니다. SQL Server 2000 데이터베이스가 SQL Server 6.5 데이터베이스에 연결된 서버를 정의하는 때를 그 예로 들 수 있습니다. SQL Server 6.5를 실행하는 서버에서 받은 모든 정보는 유효하지만 오프 코드 페이지 데이터를 삽입해서는 안됩니다.
유니코드가 아닌 서버와 클라이언트
가장 제한이 많은 구성 형태입니다. 기본적으로 항상 단일 코드 페이지로만 제한되기 때문입니다.
이전 버전 SQL Server의 다국어 데이터 변환
모든 사용자들이 SQL Server 7.0 및 SQL Server 2000에 포함된 유니코드 기능이 자신의 다국어 데이터를 처리할 때까지 기다릴 수는 없습니다. 일부 사용자들이 이러한 데이터를 저장하기 위해 사용자 지정 인코딩 구성표를 만들었습니다. 이와 같이 생각하는 사용자라면 먼저 대량 복사 유틸리티(bcp)를 사용하여 변환 없는 이진 데이터로 데이터를 저장한 다음 -C 명령줄 매개 변수와 적절한 코드 페이지를 사용하여 다시 역으로 대량 복사해야 합니다. bcp 유틸리티에 대한 자세한 내용은 이 기사 뒷부분의 다국어 데이터에 bcp 유틸리티 사용을 참조하십시오.
Access 2000의 새 ADP 형식 사용
Microsoft Access 2000은 Jet 데이터베이스가 아니라 ADP(Access Data Project)인 새 파일 형식 옵션을 추가합니다. 이러한 파일은 직접 SQL Server의 프런트 엔드로 동작할 수 있습니다.
ADP 기능에 대한 설명은 이 기사의 범위를 넘어서므로 두 가지 중요한 사안만 지적하도록 하겠습니다.
- Access 2000은 SQL Server 2000 클라이언트 도구가 설치되어 있지 않으면 SQL Server 2000을 지원하지 않습니다.
- Access 내의 SQL Server 데이터에 대한 모든 진입점(폼, 데이터 액세스 페이지, 테이블 데이터시트 보기, ADO)에는 Access와 SQL Server 사이에 COM이라는 하나의 층이 있습니다. 이 층이 날짜/시간 값, 숫자 및 통화 값의 입력에 영향을 미칠 수 있습니다. 클라이언트의 국가별 설정(이 경우 ADP가 있는 컴퓨터)이 데이터의 의미를 해석하는 데 사용되기 때문입니다. 어떤 경우 SQL Server의 규칙이 덜 제한적이기 때문에 Access를 사용할 때 이 사실을 염두에 두어야 합니다. 자세한 내용은 이 기사 뒷부분의 COM의 로케일 간섭 처리를 참조하십시오.
사용자 인터페이스의 다국어 데이터
SQL Server는 무엇보다 서버이지만 많은 관리 도구를 제공합니다. SQL Server 2000에서는 필요에 따라 다국어 데이터를 지원하도록 이러한 도구가 업데이트되었습니다.
일반 UI 변경 사항(유니코드 지원)
SQL Server 엔터프라이즈 관리자는 현재의 기본 코드 페이지 또는 서버 코드 페이지에 있는 테이블 이름을 다루는 데 뛰어납니다. 또한 아래 그림 14에 나온 것처럼 Windows의 글꼴 연결 기술을 사용하여 필요에 따라 다른 글꼴에서 문자를 "빌립니다."
[그림 14] 글꼴 연결 기능 예제
그림에서 볼 수 있듯 글꼴 연결이 완벽하게 동작하는 것은 아닙니다. 아르메니아어, Sylfaen, 그루지야어, 힌디어 등 Windows에 고급 글꼴 연결 정보가 없는 언어도 많이 있습니다. 또한 아제리어(키릴 자모) 등 어떤 언어가 스크립트에 자주 사용되지 않는 문자를 사용하는 경우 대부분의 문자열은 표시되지만 몇몇 문자는 표시되지 않습니다.
주목할 만한 세 가지 문제가 있습니다.
- 해당 글꼴 및 글꼴 연결에서 이름을 지원하지 않을 때는 깨진 문자가 나타나는 대신 위 그림처럼 상자가 나타나 표시할 수 없는 문자가 있다는 것을 알려줍니다.
- Windows 2000을 사용하지 않는 경우 SQL Server 2000 클라이언트 도구가 복잡한 스크립트를 렌더링하는 데 유니스크라이브(Uniscribe) 기술을 사용하기 때문에 위 그림에 나온 것처럼 히브리어, 이디시어, 아랍어, 페르시아어 같은 양방향 언어의 문자가 거꾸로 표시됩니다. 그러나 Windows 2000 및 BIDI 사용 가능 플랫폼에서는 이러한 문자가 올바르게 표시됩니다. Windows 2000을 사용하지 않는다 하더라도 태국어의 단어 분리 같은 다른 복잡한 스크립트 렌더링 문제에도 같은 제한이 적용됩니다.
- SQL Server 엔터프라이즈 관리자에 사용되는 "기본" 글꼴은 컴퓨터의 바탕 화면 디스플레이 설정에서 정의되는 것이므로 덮어쓸 수 없습니다.
SQL 쿼리 분석기의 표 형태 및 SQL 창에 나타나는 다국어 정보
SQL Server 엔터프라이즈 관리자에서는 글꼴을 변경할 수 없습니다. 그러나 SQL 쿼리 분석기의 옵션 대화 상자에 있는 글꼴 탭(그림 15)에서 사용자 인터페이스의 많은 부분에 대해 글꼴을 명시적으로 변경할 수 있습니다.
[그림 15] SQL Server 2000 쿼리 분석기의 글꼴 대화 상자
글꼴 연결 기능을 통해 대부분의 문자열을 표시할 수 있는 것처럼 보이기 때문에 처음에는 왜 이 작업을 해야 하는지 분명하지 않을 수 있습니다. 그러나 문자열을 올바르게 표시한다는 것은 단순히 문자를 나타낼 수 있는 글꼴을 찾는다는 것 이상의 의미를 가집니다. 어떤 글꼴을 선택하느냐에 따라 결과가 달라지는 경우가 많습니다. 따라서 이 기능은 다국어 데이터를 올바르게 나타내는 데 중요할 수 있습니다. 글꼴 연결이 동작하지 않는 경우 이 기능이 상자가 아닌 문자열이 표시되도록 할 것입니다.
쿼리 디자이너의 형식 문제
쿼리 디자이너에서는 대부분 컴퓨터의 기본 국가별 설정과 일치하는 표 형태 창에 정보를 입력하거나 명시적으로 CONVERT 함수를 사용하여 임의 형식의 문자열이 처리되도록 할 수 있습니다.
국가별 설정을 사용하는 방법과 관련하여 몇 가지 디자인 제한 사항을 알아두는 것이 좋습니다.
- 긴 데이터 형식은 지원되지 않습니다.
- 미국 달러 기호($)는 선택적으로 사용할 수 있지만 표 형태 창에 통화 기호를 입력하면 안됩니다. 어느 쪽이든 국가별 설정에서 검색된 통화 기호가 결과 창에 사용됩니다.
- 국가별 설정과 상관없이 빼기 기호가 항상 괄호 없이 왼쪽에 나타납니다. 따라서 -1은 1-, (1) 또는 국가별 옵션 대화 상자에 지정된 다른 어떤 유효한 변형이 아닌 -1로 표현됩니다.
이러한 제한 사항은 쿼리 디자이너에 어느 정도의 국제적 지원 기능을 포함하기 위해 필요하며 실제로 로케일별 데이터를 사용하려는 노력을 방해하는 요소는 아닙니다.
표 형태 창에 입력된 모든 정보는 SQL 창에서 로케일 독립적 형식으로 변환되므로 표준 독일어를 사용하는 컴퓨터의 "03.09.65"는 { ts ' 1965-09-03 00:00:00 }로 변환됩니다. SQL 창에 직접 입력한 모든 데이터는 이 형식을 사용해야 하며 그렇지 않으면 명시적 CONVERT 호출을 포함해야 합니다.
정렬 순서
결과 창에 표시된 데이터의 정렬은 국가별 설정의 영향을 받지 않습니다. 대신 데이터 정렬 규칙(이 기사 앞부분의 SQL Server 2000의 데이터 정렬 참고)이 ORDER BY 절의 해석 방법을 제어합니다.
더블바이트(DBCS) 문자
리터럴 및 데이터베이스 개체 이름, 별칭, 매개 변수 이름, 매개 변수 표식 문자에 DBCS 문자를 사용할 수 있습니다. 그러나 함수 이름 또는 SQL 키워드 같은 SQL 언어 요소에는 DBCS 문자를 사용할 수 없습니다. 따라서 일본어 전자 대신 SELECT 키워드를 사용해야 합니다. 
SQL Server 데이터 액세스(데이터 액세스 방법)
SQL Server의 데이터에 액세스하는 방법이 매우 중요합니다. 여러 가지 데이터 액세스 방법이 있으며 이들 각각의 다국어 텍스트 처리 규칙 또한 매우 중요합니다. 다음 절들에서 몇 가지 데이터 액세스 방법에 대해 설명합니다.
OLE DB
OLE DB는 MDAC(Microsoft Data Access Components)의 핵심 구성 요소이며 SQL Server 7.0에는 MDAC 버전 2.1, SQL Server 2000에는 MDAC 버전 2.6이 제공됩니다. OLE DB는 COM을 기반으로 하기 때문에 모든 문자열이 유니코드 BSTR(Windows 2000에서는 UTF-16, 다른 운영 체제에서는 UCS-2)입니다. SQL Server의 경우 SQL Server용 Microsoft OLE DB 공급자(SQLOLEDB)가 공급자입니다. 데이터는 필요에 따라 실제 데이터의 데이터 정렬을 사용하여 유니코드로 변환됩니다. 프로세스 전체에 걸쳐 데이터를 유니코드로 유지해야 최적화된 성능을 얻을 수 있습니다.
ADO
Microsoft ActiveX® Data Objects는 OLE DB의 래퍼로 동작하는 Visual Basic 및 스크립팅 친화적 인터페이스입니다. 또한 COM 구성 요소이기도 하므로 유니코드에 대해 같은 지원을 제공합니다. 둘 사이에 변환이 가능하도록 하는 방식으로 ADO와 OLE DB를 분리할 방법은 없습니다. 따라서 문제는 언제나 OLE DB 층에서 발생합니다.
ODBC
ODBC가 유니코드 층인지 아닌지는 사용되는 ODBC 버전에 달려 있습니다. ODBC 사용에 적용되는 규칙에 대한 자세한 내용은 이 기사 앞부분의 서버와 클라이언트 간의 통신을 참조하십시오.
DB-Library
최신 유니코드 버전의 DB-Library가 없습니다. 자세한 내용은 이 기사 앞부분의 서버와 클라이언트 간의 통신을 참조하십시오.
SQL-DMO
SQL 분산 관리 개체(SQL-DMO)는 SQL Server 2000 데이터베이스와 복제 관리를 캡슐화하는 COM 계층입니다. COM이기 때문에 ADO와 OLE DB에 적용되는 규칙이 SQL-DMO에도 적용됩니다. SQL-DMO는 또한 SQLServer2, Database2, Column2, SystemDateType2 및 UserDefinedDataType2 개체의 Collation 속성 등 앞에서 언급한 기능에 사용될 수 있는 속성을 가집니다.
다국어 Transact-SQL
다국어 데이터가 포함된 서버에 SQL 문을 보낼 때 데이터가 서버에서 올바르게 처리되느냐는 주로 아래의 두 요소에 달려 있습니다.
- SQL 문 자체의 인코딩
- 문 안의 문자열 리터럴의 인코딩
SQL 문 안의 문자열 리터럴의 인코딩
SQL 문자열 자체의 인코딩 후 문자열 리터럴을 처리하기 위한 기술 또한 사용되어야 합니다. 본질적으로 컴퓨터의 기본 코드 페이지로 된 문자열 또는 유니코드 문자열만 선택할 수 있습니다. 유니코드 문자열은 아래와 같이 문자열 앞에 National을 뜻하는 접미사 "n"을 추가하여 지정합니다.
"n" 접두사가 없으면 이 문자열(힌디어의 힌디 단어)은 "??????"로 변환됩니다. 코드 페이지가 있지만 시스템 기본값과 일치하지 않는 데이터에서도 이런 일이 발생합니다.
경고: 문자열 리터럴과 데이터 형식(nchar, nvarchar, ntext)에 유니코드 데이터를 나타내기 위해 접두사 "n"을 사용하는 것은 SQL Server에만 고유한 방식입니다. ANSI-92 SQL 명세는 국가 표준 문자 데이터 형식을 정의하지만 유니코드일 것을 요구하지는 않습니다. SQL Server 2000 릴리스 시 완성되지 않은 상태였고 유니코드 지원과 관련하여 논의와 수정이 예상되는 ANSI-99 SQL 명세는 접두사 "u"를 가진 유니코드 형식 집합(예: utext, uchar, uvarchar)을 사용하는 방법을 얘기합니다. SQL Server 2000에서는 이러한 데이터 형식을 사용할 수 없습니다. 그러나 다른 일부 서버 데이터베이스 제품에서는 그렇지 않습니다. 자세한 내용은 이 기사 뒷부분의 다른 데이터베이스 제품과의 상호 작용을 참조하십시오.
SQL 문자열 인코딩
ADO를 사용하는 모든 SQL 문자열이 그러하듯 유니코드를 사용하는 SQL 문자열의 경우 어떤 종류의 문자라도 인코딩할 수 있습니다. 유니코드 이외의 배치 파일이나 .SQL 파일의 문자열처럼 유니코드를 사용하지 않는 문자열의 경우 어느 시점이 되면 변환이 이뤄져야 하며 이는 일반적으로 변환이 수행되는 컴퓨터의 기본 시스템 코드 페이지를 사용하여 이뤄집니다. 다국어 응용 프로그램에서는 이를 올바르게 계획하지 않으면 큰 문제가 발생할 수 있습니다.
문자열 리터럴이 유니코드가 아닌 경우(접두사 n으로 표시된 경우) 데이터베이스의 기본 코드 페이지를 사용하여 유니코드로 변환됩니다. 다국어 데이터에서는 유니코드 데이터 형식과 유니코드 문자열 리터럴을 사용하는 것이 가장 좋은 방법입니다.
문자열 처리 함수
Transact-SQL은 중요한 다국어 고려 사항이 있는 아래와 같은 기본 제공 문자열 처리 함수를 사용합니다.
ASCII
현재의 기본 시스템 코드 페이지를 사용하여 문자열에 있는 첫 문자의 코드 포인트를 반환합니다. 그 문자가 해당 코드 페이지에 없으면 물음표에 대한 코드 포인트인 63이 반환됩니다. 이는 Visual Basic 및 VBScript의 Asc() 함수와 비슷합니다.
CHAR
ANSI 코드 포인트가 주어진 문자를 반환합니다. 본질적으로 ASCII 함수와 반대로 동작하며 Visual Basic 및 VBScript의 Chr() 함수와 비슷합니다. 코드 포인트가 0-255 범위 안에 없으면 Null을 반환합니다.
NCHAR
CHAR 함수에 해당하는 유니코드 함수입니다. 유니코드 코드 포인트가 주어진 문자를 반환합니다. Visual Basic 및 VBScript의 ChrW() 함수와 비슷합니다.
UNICODE
ASCII 함수에 해당하는 유니코드 함수이며 문자열에 있는 첫 문자의 유니코드 코드 포인트를 반환합니다. Visual Basic 및 VBScript의 AscW() 함수와 비슷합니다.
이 기사의 앞부분에서 원하는 형식을 얻기 위해 NCHAR 함수를 사용하여 회교 날짜 앞에 RLM(right to left mark)을 추가한 예제가 있었습니다(날짜/시간 형식: datetime, smalldatetime 참고).
SQL Server 2000의 로케일 지원
SQL Server 2000에는 33개 언어에 대한 약간 특별한 로케일 지원이 제공됩니다. 이는 Windows의 NLS 데이터베이스에서 사용할 수 있는 완전 로케일 지원은 아니지만 많은 기본 기능을 제공합니다. 아래 목록은 지원되는 언어를 영어와 해당 언어로 표시한 것입니다.
SQL Server 2000 및 Windows 2000에서 지원하는 언어 목록
| 영어 | 해당 언어 |
| Arabic | Arabic |
| British English | British |
| Brazilian | Português - Brasil |
| Bulgarian |  |
| Simplified Chinese |  |
| Traditional Chinese |  |
| Croatian | hrvatski |
| Czech |  |
| Danish | Dansk |
| Dutch | Nederlands |
| English | us_english |
| Estonian | eesti |
| Finnish | Suomi |
| French |  |
| German | Deutsch |
| Greek |  |
| Hungarian | magyar |
| Italian | Italiano |
| Japanese |  |
| Korean | |
| Latvian | Latviešu |
| Lithuanian | lietuviø |
| Norwegian | Norsk |
| Polish | polski |
| Portuguese | Português |
| Romanian | românã |
| Slovak | slovenéina |
| Slovenian | slovenski |
| Spanish | Español |
| Swedish | Svenska |
| Thai |  |
| Turkish |  |
| Russian |  |
sp_helplanguage 저장 프로시저를 사용하여 이들 언어 및 언어에 대한 정보를 열거할 수 있습니다. 모든 SQL Server 버전이 위에 나열된 많은 항목에 대한 전체 정보를 저장하지만 지역화된 제품을 설치하지 않는 한 번역된 시스템 메시지는 나타나지 않습니다.
언어 정보는 syslanguages 테이블에 저장되며 메시지는 sysmessages에 저장됩니다.
언어 설정
모든 SQL Server는 날짜 형식 및 메시지 같은 항목을 다루는 데 사용하는 기본 언어를 가지고 있습니다. 이 정보는 서버에 로그인할 때마다 저장되며 설치 시 처음부터 설정되지만 그림 16처럼 SQL Server 속성 대화 상자의 서버 설정 탭을 사용하여 서버 수준에서 덮어쓸 수 있습니다.
[그림 16] SQL Server 언어 설정 대화 상자
또한 예를 들어 아래와 같이 호출에 sp_configure 저장 프로시저를 사용하여 기본 언어를 이탈리아어로 변경할 수 있습니다.
sp_configure "language", 6 아래 표는 syslanguages 테이블의 쿼리를 사용하여 쿼리할 수 있는 사용 가능한 언어 ID(langid)를 나타낸 것입니다.
| langid | 언어 이름 |
| 0 | English |
| 1 | German |
| 2 | French |
| 3 | Japanese |
| 4 | Danish |
| 5 | Spanish |
| 6 | Italian |
| 7 | Dutch |
| 8 | Norwegian |
| 9 | Portuguese |
| 10 | Finnish |
| 11 | Swedish |
| 12 | Czech |
| 13 | Hungarian |
| 14 | Polish |
| 15 | Romanian |
| 16 | Croatian |
| 17 | Slovak |
| 18 | Slovenian |
| 19 | Greek |
| 20 | Bulgarian |
| 21 | Russian |
| 22 | Turkish |
| 23 | British English |
| 24 | Estonian |
| 25 | Latvian |
| 26 | Lithuanian |
| 27 | Brazilian |
| 28 | Traditional Chinese |
| 29 | Korean |
| 30 | Simplified Chinese |
| 31 | Arabic |
| 32 | Thai |
sp_addlogin 저장 프로시저를 사용하거나 그림 17처럼 로그인 속성 대화 상자를 사용하여 로그인할 때마다 기본 언어 설정을 덮어쓸 수 있습니다.
[그림 17] 로그인 속성 대화 상자
마지막으로, 아래 예제처럼 SET LANGUAGE 문을 사용하여 세션 수준에서 언어를 덮어쓸 수 있습니다.
문자열 앞에 접두사 n을 사용하여 유니코드로 처리되도록 해야 합니다. 이렇게 하면 서버의 기본 시스템 코드 페이지를 사용하여 변환할 때 발생할 수 있는 원치 않는 문제를 피할 수 있습니다.
각각의 데이터 액세스 방법은 SET LANGUAGE 호출 외부에서 언어 설정을 지정하는 고유한 방법을 제공합니다.
- ADO는 ConnectionString에서 공급자별 언어 키워드를 지원합니다.
- OLE DB는 공급자별 SSPROP_INIT_CURRENTLANGUAGE 속성을 설정할 수 있습니다.
- ODBC는 데이터 원본 정의 또는 연결 문자열의 LANGUAGE 키워드에 언어를 지정할 수 있습니다.
- DB-Library는 dblogin을 사용하여 LOGINREC를 할당한 다음 DBSETNATLANG를 사용하여 언어 설정을 지정할 수 있습니다.
언어 설정이 서버, 로그인 또는 세션 등 어느 수준에서 정의되었느냐에 따라 아래 항목이 영향을 받습니다.
- 메시지
- 날짜/시간
- 시작 요일
- 통화 및 통화 기호
- 월/요일 이름 및 월 이름의 약어
메시지
SQL Server 2000에서는 언어별 시스템 오류 문자열 및 메시지를 유지할 수 있습니다. 이러한 메시지는 master 데이터베이스의 sysmessages 테이블에 저장됩니다. 지역화된 SQL Server 2000을 설치할 때 이러한 시스템 메시지가 설치하는 언어에 맞게 번역됩니다. 또한 기본적으로 미국 영어로 된 메시지 집합이 제공됩니다. 언어 설정을 사용하여 서버 세션의 언어를 지정할 수 있습니다. 기본적으로는 설치된 버전의 언어가 사용됩니다. 연결에 메시지를 보낼 때 SQL Server는 언어 ID 집합이 sysmessages 테이블의 msglangid 열에 있는 언어 ID 가운데 하나와 일치하면 번역된 메시지를 사용합니다. 이러한 ID는 10진수 형식이며 메시지의 로케일 ID(LCID)를 나타냅니다. 같은 LCID를 가진 메시지가 sysmessages 테이블에 없으면 미국 영어 메시지가 사용됩니다.
sp_addmessage 시스템 저장 프로시저의 @lang 매개 변수를 사용하여 sysmessages 테이블에 언어별 사용자 정의 메시지를 추가할 수 있습니다. 오류 수는 50,000개가 넘습니다. 메시지의 언어는 @lang이며 LCID로 매핑되는 명명된 별칭입니다.
서버에 각기 다른 언어별 시스템 오류 문자열 및 메시지를 설치할 수 있기 때문에 language 값이 sysmessages 테이블에 쓰일 메시지의 언어를 지정합니다. language를 생략하면 서버 세션의 기본 언어가 사용됩니다. 지원되는 언어 정의는 master.dbo.syslanguages에 저장됩니다. 각기 다른 언어별 sysmessages를 설치하려면 기술 지원 서비스(PSS) 담당자에게 문의하십시오.
날짜/시간
우선 간단한 날짜 형식을 mdy, dmy 또는 ymd로 변경할 수 있습니다. SET DATEFORMAT 설정을 사용하여 연결 수준에서 이 설정을 덮어쓸 수 있지만 각 언어는 적절한 기본값을 가지고 있습니다. 기본값은 sp_helplanguage 저장 프로시저를 사용하여 검색할 수 있습니다. 값은 dateformat 열에 저장됩니다.
시작 요일
시작 요일은 로케일마다 다릅니다. syslanguages 테이블에 포함된 33개 언어의 시작 요일은 1(월요일)부터 7(일요일)까지 다양합니다. 이 정보는 sp_helplanguage 저장 프로시저를 사용하여 검색할 수 있습니다. 값은 datefirst 열에 저장됩니다.
통화 및 통화 기호
money 또는 smallmoney 형식의 모든 열에 통화 기호를 포함할 수 있습니다. 국가별 옵션 대화 상자에 지정된 기호뿐만 아니라 아래 표에 나열된 문자 중 어떤 것이라도 사용할 수 있습니다.
| 통화 기호 | 통화 이름 | 유니코드(16진수) 값 |
| $ | 달러 기호(미국) | 0024 |
 |
파운드 기호(영국) | 00A3 |
 |
(유니버설) 통화 기호 | 00A4 |
 |
엔 기호 | 00A5 |
 |
벵골 루피 마크 | 09F2 |
 |
벵골 루피 기호 | 09F3 |
 |
태국 바트 기호 | 03EF |
 |
콜론 기호 | 20A1 |
 |
크루제이로 기호 | 20A2 |
 |
프랑스 프랑 기호 | 20A3 |
 |
리라 기호 | 20A4 |
 |
나이라 기호 | 20A6 |
 |
페세타 기호 | 20A7 |
 |
루피 기호 | 20A8 |
 |
원 기호 | 20A9 |
 |
신 셰켈 기호 | 20AA |
 |
동 기호 | 20AB |
 |
유로 기호 | 20AC |
SQL Server 2000 온라인 설명서에는 유로 기호의 16진수 값이 20A0으로 잘못 표기되어 있습니다. 20AC가 실제 값입니다. 20A0이 나타내는 문자 
는 유로화(ECU) 기호입니다. 이는 유로가 아니므로 그렇게 사용하면 안됩니다. 통화 값에 이 기호 를 사용하면 오류 메시지가 나타납니다.
월/요일 이름 및 월 이름의 약어
syslanguages 테이블에 월 및 요일 이름이 포함됩니다. 아래와 같은 열을 사용하여 sp_helplanguage 저장 프로시저로 이들을 검색할 수 있습니다.
months
1월부터 12월까지 쉼표로 구분된 월 이름 목록
shortmonths
1월부터 12월까지 쉼표로 구분된 약어 월 이름 목록
days
월요일부터 일요일까지 쉼표로 구분된 요일 목록
COM의 로케일 간섭 처리
날짜/시간 및 통화 값 처리와 관련하여 SQL Server가 몇 가지 뛰어난 기능을 제공하긴 하지만 ADO 같은 COM 서비스를 사용하여 서버에 액세스하는 경우 COM 간섭을 고려해야 합니다. 예를 들어, 위의 표에 나온 것처럼 통화 기호 뒤에 나오는 숫자 값이 통화 값이라는 사실을 Visual Basic이 인식하도록 하는 데 문제가 있을 수 있습니다. 또한 COM이 문자열에 저장된 날짜/시간 값을 올바르게 사용하도록 하는 데 심각한 문제가 있을 수 있습니다.
이 문제를 올바르게 처리하려면 응용 프로그램이 언제 문자열을 날짜/시간 또는 통화 값으로 변환하는지 알아야 합니다. 변환이 클라이언트에서 일어나는지 서버에서 일어나는지 알게 되면 어떤 규칙을 적용해야 할지 결정할 수 있습니다.
Access 2000 ADP가 이러한 클라이언트의 예입니다. 이 기사 앞부분의 Access 2000의 새 ADP 형식 사용을 참조하십시오. Access는 OLE DB를 통해 동작하기 때문에 Access 2000의 모든 동작에는 클라이언트 컴퓨터의 국가별 설정을 사용하는 COM 규칙이 적용됩니다.
참고 SQL Server용 Microsoft OLE DB 공급자 같은 OLE DB 공급자는 유효한 COM 날짜를 SQL Server 날짜로 또는 그 역으로 변환할 것입니다. 가능한 한 문자열의 날짜 형식에는 의존하지 않는 것이 좋습니다. 클라이언트쪽의 로케일이 바뀌면 손상될 수 있는 기능이기 때문입니다.
데이터 변환 서비스
그림 18에 나온 것처럼 다국어 데이터를 다룰 때 DTS 가져오기/내보내기 마법사의 사용자 인터페이스에 몇 가지 주목할 문제가 있습니다.
[그림 18] DTS 마법사 대화 상자
이 마법사는 유형이 다른 데이터를 처리할 수 있는 인터페이스를 제공합니다. SQL Server 엔터프라이즈 관리자 및 SQL 쿼리 분석기처럼 완벽한 유니코드가 가능하지 않은 데이터를 표시하는 대화 상자가 몇 개 있습니다. 이 기사 앞부분의 사용자 인터페이스의 다국어 데이터를 참조하십시오. 이 때문에 데이터가 마법사에서 올바르게 표시되지는 않지만 올바르게 전송되는 상황이 있을 수 있습니다. DTS의 안정성은 이러한 UI 제약의 영향을 받지 않습니다. 대부분의 경우 단순히 데이터를 볼 수 없을 뿐입니다. 그림 19에 나온 것처럼 데이터가 상자로 바뀌기 때문입니다.
[그림 19] DTS 마법사
이 그림은 중국어 간체 데이터가 포함된 유니코드 텍스트 파일을 나타낸 것입니다. 유니코드 텍스트 열로 가져오든 중국어 간체 텍스트 열로 가져오든 가져온 데이터는 올바르게 처리됩니다.
그러나 시스템 기본값에 없는 특정 코드 페이지를 사용하는 텍스트 파일의 경우 그림 20에 나온 것처럼 마법사에 그 텍스트를 읽을 수 있는 적절한 컨텍스트가 없습니다. 이 제약은 여러 프로그램에서 드물지 않게 나타납니다. 메모장 및 워드패드 등 많은 프로그램이 예상치 않은 코드 페이지를 사용하는 파일을 읽을 수 있는 기능을 가지고 있지 않습니다.
[그림 20] DTS 마법사를 사용하여 올바르게 가져올 수 없는 파일의 예
이 한국어 파일은 영어를 사용하는 컴퓨터로 올바르게 가져올 수 없으며 마법사는 가져오기 프로세스의 코드 페이지를 지정할 수 있는 방법을 제공하지 않습니다. 데이터를 올바르게 표시하거나 가져올 수 없는 이유가 여기에 있습니다. 다른 많은 경우처럼 규칙은 매우 명료합니다. 즉, 다국어 데이터를 사용하려면 유니코드를 사용해야 합니다.
DTS 변환 시 인코딩 정보에 사용할 수 있는 규칙으로 "use src," "use dest" 또는 "use collation"이 있습니다.
"use collation" 옵션을 사용할 때 원하는 결과를 얻을 가능성이 가장 높습니다. 이 옵션은 실제로 SQL-DMO 및 DTS 디자이너의 기본값입니다. DTS 마법사의 기본값은 아니지만 쉽게 설정할 수 있습니다. "use collation" 옵션은 원본과 대상 모두 SQL Server 2000 데이터베이스일 때만 동작하지만 해당 열의 데이터 정렬 정보를 사용하여 가장 적합한 전송 방법을 결정합니다.
나머지 두 변환 옵션은 그다지 유연하지 않으며 서버의 원본 또는 대상 코드 페이지를 사용하여 변환 방법을 결정해야 합니다. 불행히도 이러한 설정은 서버의 코드 페이지 설정을 충실하게 고수합니다. 따라서 특정 다중 인스턴스 서버의 데이터 정렬을 무시하지는 않지만 서버와 다른 데이터베이스 데이터 정렬은 지원하지 않습니다.
DTS 변환 작업이 가진 다른 뛰어난 기능으로는 SQL Server 인스턴스의 NLS 정보를 사용하여 datetime 이외의 데이터 및 문자열을 변환하는 기능이 있습니다. 날짜/시간 데이터를 문자열로 저장하는 형식의 경우 이 우수한 기능을 통해 사용자가 기대하는 방식대로 가져오기가 이뤄질 수 있습니다. 모든 형식이 SQL Server 2000처럼 많은 데이터 형식을 가지고 있는 것은 아니므로 이 사실은 매우 중요하며 DTS는 이러한 제한된 형식과 서버의 성능을 연결하는 중요한 다리 역할을 합니다.
원본이 SQL Server 7.0이고 대상이 SQL Server 2000인 유니코드 이외의 열 간에 데이터를 이동할 때 SQL Server 2000 열의 데이터 정렬이 SQL Server 7.0에서 쉽게 나타낼 수 있는 데이터 정렬이 아닌 경우 또 다른 DTS 문제가 발생할 수 있습니다. 반대로, SQL Server 2000 원본과 SQL Server 7.0 대상도 같은 문제를 일으킬 수 있습니다. 이러한 경우에 SQL Server 7.0 엔드에서 서버 코드 페이지가 기본값으로 사용됩니다. 다시 한번 강조하지만 유니코드 데이터 형식을 사용하면 이러한 문제가 발생하지 않습니다.
DTS로 변환 작업이 아니라 복사를 할 때 아래와 같은 세 가지 가능성이 있습니다.
- OLE DB 공급자 열
원시 데이터만 복사합니다. 두 열이 같은 코드 페이지의 데이터를 포함하고 있지 않으면 분명히 문제가 발생합니다. 원본과 대상이 같은 코드 페이지를 사용할 때는 속도가 매우 빠르지만 서로 다른 코드 페이지를 사용하는 데이터가 있는 열 간의 복사에는 효율적이지 않습니다.
- NCHAR를 CHAR로
DTS가 자동으로 서버의 코드 페이지를 사용하여 유니코드에서 변환합니다.
- CHAR를 NCHAR로
DTS가 자동으로 원본 서버의 코드 페이지를 사용하여 유니코드로 변환합니다.
DTS 변환 문제 요약
먼저, 유니코드 원본과 대상은 항상 동작합니다. 이 사실은 충분히 강조할 필요가 있습니다. 이제 설명하겠지만 문제는 특정 상황에서 유니코드 이외의 데이터에서만 발생합니다.
대상 테이블을 만들 때
- 원본이 SQL Server 7.0이고 SQL Server 2000 대상 서버 코드 페이지가 대상 데이터베이스 코드 페이지와 일치하지 않으면 변환이 실패합니다.
- 원본이 SQL Server 2000이고 대상이 SQL Server 7.0일 때 원본 열 데이터 정렬이 원본 서버 코드 페이지와 일치하지 않으면 변환이 실패합니다.
- 원본과 대상이 SQL Server 2000일 때 Use Collation을 선택하지 않으면 변환이 실패합니다. 선택하면 데이터가 손실되지 않습니다.
대상 테이블이 이미 존재할 때
- 원본이 SQL Server 7.0이고 SQL Server 2000 대상 서버 코드 페이지가 대상 열 코드 페이지와 일치하지 않으면 변환이 실패합니다.
- 원본이 SQL Server 2000이고 대상이 SQL Server 7.0일 때 원본 열 데이터 정렬이 원본 서버 코드 페이지와 일치하지 않으면 변환이 실패합니다.
- 원본과 대상이 SQL Server 2000일 때 아래 중 하나라도 해당되면 변환이 성공합니다.
- 원본 및 대상 열 코드 페이지가 일치하고 Use Collation을 선택했을 때
- 대상 열 코드 페이지가 대상 서버 코드 페이지와 일치하고 Use Collation을 선택하지 않았을 때
Use Collation이 True이면 데이터 전송이 변경 없이 그대로 이뤄집니다. False이면 데이터가 원본 서버 코드 페이지로 캐스트된 다음 대상 열 코드 페이지로 변환됩니다.
- 원본 및 대상 열 코드 페이지가 일치하고 Use Collation을 선택했을 때
복사 열 변환의 경우
- char 대 char는 원시 변환입니다. 원본 및 대상 열 코드 페이지가 일치하지 않으면 변환이 실패합니다.
- char 대 유니코드는 원본 데이터를 컴퓨터 코드 페이지로 캐스트한 다음 유니코드로 변환합니다. 그러나 원본 데이터가 해당 코드 페이지에 나타나지 않으면 변환이 실패합니다.
- 유니코드 대 char는 대상 코드 페이지와 상관없이 데이터를 컴퓨터 코드 페이지로 변환합니다. 대상 열 코드 페이지가 컴퓨터의 코드 페이지와 일치하지 않으면 변환이 실패합니다.
다른 경우와 마찬가지로 유니코드 대 유니코드는 실패하거나 데이터를 손상할 수 있는 변환 없이 올바르게 동작하므로 다국어 데이터 처리에 권장되는 방법입니다.
다국어 데이터에 bcp 유틸리티 사용
특정 코드 페이지에서 데이터를 가져오거나 내보낼 때 여전히 bcp 유틸리티를 사용할 수 있습니다. 이 유틸리티는 손실 없는 데이터 변환을 위해 아래 표에 나열된 플래그를 지원합니다.
| 플래그 | 의미 | 설명 및 참고 |
| -C xxx | 코드 페이지 지정자 | xxx는 코드 페이지, ANSI, OEM 또는 RAW(변환 없는 직접 복사)를 지정할 수 있습니다. 가장 빠른 옵션입니다. |
| -N | 유니코드 원시 형식 사용 | 문자가 아닌 모든 데이터에 원시(데이터베이스) 데이터 형식을 사용하고 모든 문자 데이터에 유니코드 문자 형식을 사용합니다. |
| -w | 유니코드 문자 형식 사용 | 모든 열에 유니코드 문자 데이터 형식을 사용합니다. |
또한 서식 파일을 사용하고 열 수준에서 데이터 정렬을 지정할 수 있습니다. -C, -N 또는 -w를 지정하지 않으면 가져오기/내보내기를 수행하기 전에 bcp가 실제로 각 열, 데이터 정렬, 코드 페이지 정보를 쿼리합니다. 그런 다음 pubs 데이터베이스의 authors를 참조하는 아래 예제에서처럼 서식 파일을 저장하라는 메시지를 보냅니다.
8.0 9 1 SQLCHAR 0 11 ""1 au_id Latin1_General_CI_AI 2 SQLCHAR 0 40 "" 2 au_lname Latin1_General_CI_AI 3 SQLCHAR 0 20 "" 3 au_fname Latin1_General_CI_AI 4 SQLCHAR 0 12 "" 4 phone Latin1_General_CI_AI 5 SQLCHAR 0 40 "" 5 address Latin1_General_CI_AI 6 SQLCHAR 0 20 "" 6 city Latin1_General_CI_AI 7 SQLCHAR 0 2 "" 7 state Latin1_General_CI_AI 8 SQLCHAR 0 5 "" 8 zip Latin1_General_CI_AI 9 SQLBIT 0 1 "" 9 contract "" 허용되는 데이터 형식이 아래 표에 나와 있습니다. 데이터 정렬은 열에 지정된 기본값입니다. 이는 데이터베이스나 서버에서 상속되었을 수 있습니다.
| 형식 | 전체 이름 |
| c | Char |
| T | Text |
| i | Int |
| s | Smallint |
| t | Tinyint |
| f | Float |
| m | Money |
| b | Bit |
| d | Datetime |
| x | Binary |
| I | Image |
| D | Smalldatetime |
| r | Real |
| M | Smallmoney |
| n | Numeric |
| e | Decimal |
| w | Nchar |
| W | Ntext |
| u | Uniqueidentifier |
varchar 및 nvarchar 데이터 형식은 표에 나와 있지 않습니다. bcp 유틸리티의 경우 각각 char 및 nchar 형식이 사용되어야 합니다.
마지막으로, bcp는 "국가별 설정 사용"에 -R 플래그를 지원합니다. 이 플래그는 ODBC의 "국가별 설정 사용" 옵션과 같은 역할을 하며(이 기사 앞부분의 서버와 클라이언트 간의 통신 참고) nontext 필드에 저장되는 날짜/시간, 숫자 및 통화 데이터의 해석 방식에 관련되어 있을 수 있습니다.
Microsoft Search 서비스와 FTS
많은 Microsoft 제품이 Microsoft Search 서비스를 사용하며 서비스 자체가 SQL Server 2000 및 Exchange 2000에 사용됩니다. 엔진은 인덱스 서버에 사용되는 것과 같으며 앞으로 다른 많은 제품이 이 기능을 포함할 것입니다. 가장 중요한 기능은 언어별 형태소(동사 활용) 및 단어 분리 기능입니다. 예를 들어, 프랑스어의 l'unique 같은 단어를 올바르게 색인화할 수 있습니다. Microsoft Search 서비스에서 지원하는 언어는 아래와 같습니다.
- 네덜란드어
- 영어(영국)
- 영어(미국)
- 프랑스어
- 독일어
- 이탈리아어
- 일본어
- 한국어
- 중국어 간체
- 스페인어(현대)
- 스웨덴어
- 중국어 번체
- 태국어
이러한 언어별 형태소 분석기/단어 분리기 외에 다른 언어에 사용할 언어 중립적 기능도 제공됩니다. 언어 중립적 기능 대신 특정 언어를 사용하여 더 만족할 만한 결과를 얻을 수 있는 경우도 있을 수 있습니다. 예를 들어, 카탈로니아어 대신 스페인어를 사용하고 남아공 공용어 대신 네덜란드어를 사용할 수 있습니다. 그러나 이런 경우 공식적으로 권장하는 방법은 언어 중립적 기능을 사용하는 것입니다. 따라서 단순히 "비슷한" 언어로 더 나은 결과를 얻을 수 있을 것이라고 추정하는 대신 데이터로 직접 테스트하는 것이 좋습니다. 언어 지원은 매우 정교한 사안이므로 해당 언어에 없는 데이터를 제공하려 하면 문제가 복잡해질 수 있습니다.
Microsoft Search 서비스 및 관련 구성 요소를 사용하는 다양한 공급자의 실제 구현 세부 사항은 대부분 사용자의 필요에 달려 있습니다. Exchange 저장소에서 데이터를 색인화하는 경우 Exchange 구현이 적합할 것입니다. 그러나 파일 시스템을 사용하는 경우 인덱스 서버가 적합합니다. SQL Server 2000을 사용한다면 SQL Server 2000의 전체 텍스트 검색이 가장 적합할 것입니다.
Microsoft Search 서비스는 클라이언트가 특정 언어로 된 텍스트 영역에 "태그"를 지정하여 단일 데이터 집합에 다국어 색인을 만들 수 있도록 하지만 SQL Server 2000은 이런 방식으로 데이터에 "태그"를 지정하는 것을 허용하지 않기 때문에 열 수준에서 언어를 지정해야 합니다. 그러나 단일 열에 여러 색인을 만들 수 있습니다. 단일 열에 다국어 데이터가 있고 언어별 검색을 수행하고 싶을 때 이 기능이 좋은 해결책이 될 수 있습니다. sp_fulltext_column 저장 프로시저의 @language 매개 변수를 사용하여 사용할 언어를 지정할 수 있습니다.
또한 아래와 같이 sp_configure 저장 프로시저의 default full-text language 옵션을 사용하여 전체 텍스트 검색에 사용할 기본 언어를 지정할 수 있습니다.
sp_configure 'show advanced options', 1 GO RECONFIGURE GO sp_configure 'default full-text language', 1041 GO RECONFIGURE GO 기본 언어를 사용하는 경우 sp_fulltext_column 호출에 언어를 지정할 필요가 없습니다.
전체 텍스트 검색에 자국어에 대한 지원을 어떻게 추가할 수 있느냐는 문의를 자주 받습니다. 불행히도 현재는 방법이 없습니다.
대리자 쌍(이 기사 앞부분의 대리자의 정의 참고)은 FTS 또는 Microsoft Search 서비스에서는 지원되지 않습니다. 뿐만 아니라, 이러한 값 또는 SQL Server 2000이 정의되지 않은 것으로 간주하는 문자를 기반으로 검색을 안정적으로 수행할 수 없습니다.
OLAP/계층적 데이터 처리
일반적으로, SQL Server 2000의 관계형 사용에 적용되는 유니코드 필드의 다국어 텍스트에 대한 모든 규칙이 SQL Server 2000의 Analysis Services 구성 요소에 포함된 OLAP(Online Analytical Processing Capabilities)에도 똑같이 적용됩니다. Analysis Services는 SQL Server 2000 자체가 지원할 수 있는 모든 문자를 처리할 수 있습니다. 이러한 데이터가 클라이언트 시스템의 기본 코드 페이지에 있지 않으면 OLAP의 사용자 인터페이스와 마법사에서 물음표로 표시되는 경우들이 있습니다. 그러나 이는 실제 데이터에는 영향을 주지 않으며 단순히 UI에서의 표시 문제일 뿐입니다.
OLAP와 관련하여 SQL Server 2000에서는 데이터 웨어하우스를 구성하는 계층적 데이터 구조의 각 부분에 서로 다른 데이터 정렬을 사용할 수 없습니다. 데이터 분석 전반에 걸쳐 유용한 것은 아니지만 분석을 위해 데이터를 사전순으로 분할하는 경우 등 영향받을 수 있는 경우가 있습니다. 이러한 경우 순서와 파티션을 명시적으로 정의하고 문자 순서를 추정하지 않아도 되는 다른 데이터 분할 방법을 찾아야 합니다. 이는 계층적 데이터의 표시에도 매우 유용합니다. 이러한 기능이 필요한 경우 OLAP 원본에서 반환된 데이터 하위 집합을 정렬해야 합니다.
다국어 데이터에 SQL Server 2000의 XML 지원 사용
SQL Server 2000의 rich XML 지원은 다국어 데이터를 지원하기 위한 기능을 제공하며 XML 자체의 기본 인코딩이 UTF-8을 사용하는 유니코드이기 때문에 많은 경우 SQL Server는 생성되는 XML에 UCS-2 인코딩을 사용합니다. 아래와 같은 몇 가지 방법으로 XML의 인코딩을 지정할 수 있습니다.
- ADO 스트림 개체에서 데이터를 XML 형식으로 만든 다음 스트림을 계속 유지하는 경우 출력 인코딩을 지정할 수 있으며 XML 형식 데이터에 올바른 인코딩이 지정됩니다.
- URL에 출력 인코딩을 지정할 수 있습니다.
- XML 템플릿이 인코딩을 지정할 수 있습니다.
이러한 방법을 사용하지 않더라도 기본적으로 유니코드가 지원되며 올바르게 동작합니다.
주의해야 할 점은 XML의 이름에 허용되는 문자들이 SQL Server의 식별자로 허용되는 문자들보다 훨씬 제약이 많다는 사실입니다. SQL Server 식별자를 완벽하게 지원하기 위해 XML에 지원되지 않는 식별자 문자는 _x0000_이라는 특별한 형식으로 바뀝니다. 여기에서 0000은 유니코드 코드 포인트 숫자로 바뀝니다. SQL Server는 이러한 문자를 올바르게 인식하고 정확하게 반환합니다. 업데이트그램은 모든 방식으로 인코딩을 해석합니다. 그러나 매핑 스키마가 없을 때만 이들을 사용할 필요가 있습니다.
예를 들어, 아래 Transact-SQL 문을 사용하여 UCS-2 인코딩을 사용하는 XML 파일을 만들 수 있습니다.
USE Northwind GO SELECT TOP 1 * FROM "Order Details" FOR XML AUTO DECLARE @h int EXEC sp_xml_preparedocument @h output, N'<?xml version="1.0" encoding="ucs-2"?> <root test_x0020_2="foo">
</root>'
SELECT * FROM OPENXML(@h,'/root') WITH("test 2" varchar(200) ) EXEC sp_xml_removedocument @h 이 스크립트는 키릴 자모 문자열 을 인코딩하는 XML 문서를 만듭니다. 이 문자열은 우연히 Ukranian이라는 언어 이름을 나타내는 단어입니다.
SQL Server 2000에는 XPath 지원과 함께 주석 스키마가 제공됩니다. 업데이트그램은 현재 웹에서 베타 릴리스 상태이며 2001년 초에 최종 릴리스가 있을 것입니다. 두 기능 모두 다국어 텍스트에서 잘 동작하도록 만들어졌으며 인코딩을 지정하는 방법을 지원합니다. 또한 앞에서 언급한 식별자 사용을 위한 구문도 지원합니다.
다른 데이터베이스 제품과의 상호 작용
다른 데이터베이스 시스템을 사용할 때 가장 중요한 작업은 해당 시스템의 코드 페이지 및 유사한 규칙을 결정하는 것입니다. SQL Server 쪽을 염두에 둘 때 권장되는 대부분의 데이터 액세스 방법은 COM과 관련되어 있으며 따라서 유니코드 데이터를 사용합니다. 그러므로 국제 범용 응용 프로그램이 서로 간에 얼마나 잘 실행될 수 있는지 확인하는 주된 방법은 다른 데이터베이스 제품이 유니코드를 얼마나 잘 지원하는지 확인하는 것입니다.
예를 들어, Oracle 및 Sybase SQL Server 같은 다른 데이터베이스 제품은 UTF-8 인코딩을 사용하여 유니코드를 지원합니다. 일반적으로 사용자가 정보를 보기 전에 ADO/OLE DB를 사용하여 데이터가 UTF-16으로 변환되기 때문에 사용자는 영향을 받지 않습니다. 그러나 이러한 제품의 데이터를 직접 다루려는 경우 그 차이를 알아야 합니다.
다른 중요한 문제는 Sybase SQL Server 같은 제품은 국가 표준 문자 데이터 형식을 지원하지만 이들을 유니코드 데이터 형식으로 다루지 않는다는 사실입니다. 이들의 경우 예를 들어, nchar 및 nvarchar는 그렇지 않으면 미국 영어 데이터베이스일 데이터베이스에 일본어 데이터를 저장하는 데 사용할 수 있는 필드입니다. 다른 제품에 대해 쿼리를 실행할 때 다른 데이터베이스에서 정보가 어떻게 처리되는지 잘 알아야 합니다. 그래야만 OPENROWSET 같은 명령을 사용하여 국제 범용 텍스트를 올바르게 처리할 수 있습니다. 국가 표준 문자 데이터 형식을 사용하여 유니코드 텍스트를 지정하는 것은 모든 언어를 지원하는 인코딩을 올바르게 처리하기 위해 Microsoft SQL Server가 사용하는 고유한 방식입니다.
결론
Microsoft SQL Server 2000은 뛰어난 국제 범용 기능을 많이 제공합니다. SQL Server 7.0을 기반으로 구축된 최초의 진정한 다국어 가능 버전인 SQL Server 2000은 진정한 국제적 응용 프로그램의 작성을 가능하게 하는 우수한 기능 집합을 제공합니다. 인터넷과 World Wide Web의 중요성 때문에 이 요구 사항을 만족하는 응용 프로그램 및 데이터베이스가 중요해지고 있으며 점증하는 전자 상거래 및 국제 통신도 이들을 지원할 수 있는 데이터베이스 제품을 요구하고 있습니다. SQL Server 2000은 국제적 조직체에 안성맞춤인 데이터베이스입니다.
감사
많은 사람들의 노고 없이는 이 기사가 불가능했을 것이므로 이 자리를 빌어 감사를 드립니다.
지역화에 중점을 둔 SQL Server 프로그램 관리자인 Michael Kung은 이 기사의 많은 부분에 대해 귀중한 검토 자료를 제공해 줬을 뿐만 아니라 필자가 익숙하지 않은 분야에 관한 모든 질문에 대해 적임자를 찾을 수 있도록 도움을 줬습니다. 다방면에 걸친 그의 폭넓은 지식은 이 기사를 떠나 항상 아주 큰 리소스였으며 그의 도움에 깊은 감사를 드립니다.
Peter Carlin은 SQL Server의 관계형 엔진 등을 책임지고 있는 제품 개발 관리자로서 다른 어느 누구보다 많은 의견을 개진해 줬으며 SQL Server의 유니코드 지원에 관한 중요한 많은 정보를 전자 메일로 보내줬습니다. 이 전자 메일이야말로 거의 25배나 늘어난 이 기사를 쓰게 만든 직접적인 계기였습니다.
수석 국제 프로그램 관리자인 Fernando Caro는 SQL Server의 OLAP 기능을 모두 안내해 줬음은 물론 "죄송하지만 지원되지 않습니다." 같은 무뚝뚝한 지역화 시스템 메시지를 적절한 리소스를 가리키는 유용한 포인터로 바꿀 수 있도록 도와줬습니다. 필자는 이 기사를 통해 문제점을 지적할 수 있었던 데 대해서도 감사하게 생각하지만 문제 해결이 중요하다고 지적한 Fernando와 Peter에 더욱 감사드립니다. SQL Server가 이토록 우수한 제품이 될 수 있었던 것은 이들처럼 항상 사용자들을 합리적인 방식으로 지원하려 노력하는 사람들 덕분입니다.
필자는 또한 몇몇 프로그램 관리자와 테스터의 지원에 감사를 전하고 싶습니다. 이들의 도움이 없었다면 SQL Server 제품 전체에 분산되어 있는 많은 국제 범용 기능과 문제들을 이 기사에 실을 수 없었을 것입니다. 이점에서 Michael Rys, Euan Garden, Fadi Fakhouri와 James Howey에게 감사를 드립니다. 또한 SQL Server 전체 텍스트 검색의 기반이 되는 Microsoft Search 서비스가 어떻게 동작하는지 이해할 수 있도록 해준 뛰어난 통찰력의 Margaret Li에게도 감사를 드립니다.
많은 Windows 2000 팀원들 또한 큰 도움이 되었습니다. 이들은 데이터 정렬 및 로케일 지원 같은 기본 기능이 어떻게 동작하는지에 대한 정보를 제공해 줬음은 물론 SQL Server 7.0과 2000 데이터 정렬 지원의 기반이 되는 원본 데이터를 제공해 줬습니다. 각종 질문에 친절히 답해 주고 막힌 글을 풀어나갈 수 있도록 격려를 아끼지 않은 Julie Bennett, Cathy Wissink, John McConnell에게 특별히 감사드립니다.
물론, SQL Server의 국제 범용 기능 및 다국어 기능의 계획, 개발, 테스트에 참여한 사람들을 모두 나열하려면 이 제품에 참여한 사람들을 모두 나열해야 할 것입니다. 이러한 기능은 분명히 "추가 기능"이 아니라 SQL Server 2000의 핵심 요소이기 때문입니다. 따라서 이처럼 국제적으로 유용한 제품을 만드는 데 기여한 모든 분들에게 감사의 마음을 전합니다.
필자 소개
Michael Kaplan은 Microsoft Visual Basic, Microsoft SQL Server, Microsoft Access 및 ASP 응용 프로그램의 국제화 및 지역화를 전문으로 하는 소프트웨어 개발, 컨설팅 회사인 Trigeminal Software, Inc의 사장이자 수석 개발자입니다. 그의 저작으로는 Sams Publishing에서 출간된 Internationalization with Visual Basic이 있으며 2001년 중반 다음 저작인 Internationalization with SQL Server가 출간될 예정입니다. 또한 필자는 국제 범용 기능의 개발에 관한 많은 기사를 쓰고 강연을 했습니다. 전자 메일 주소는 michka@trigeminal.com이며 Trigeminal Software, Inc.의 웹 사이트는 http://www.trigeminal.com/입니다.
이 문서에 포함된 정보는 문서를 발행할 때 논의된 문제들에 대한 Microsoft Corporation의 당시 관점을 나타냅니다. Microsoft는 변화하는 시장 환경에 대처해야 하므로 이를 Microsoft 측의 책임으로 해석해서는 안 되며 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft는 그 정확성을 보장하지 않습니다.
이 기사는 정보 제공의 목적으로만 제공됩니다. 이 기사의 정보에 대해 Microsoft는 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.
해당 저작권법을 준수하는 것은 사용자의 책임입니다. 저작권에서의 권리와는 별도로, 이 기사의 어떠한 부분도 Microsoft의 명시적인 서면 승인 없이는 어떠한 형식이나 수단(전기적, 기계적, 복사기에 의한 복사, 디스크 복사 또는 다른 방법) 또는 목적으로도 복제되거나, 검색 시스템에 저장 또는 도입되거나, 전송될 수 없습니다.
Microsoft가 이 기사 본안에 관련된 특허권, 상표권, 저작권, 또는 기타 지적 재산권 등을 보유할 수도 있습니다. 서면 사용권 계약에 따라 Microsoft로부터 귀하에게 명시적으로 제공된 권리 이외에, 이 문서의 제공은 귀하에게 이러한 특허권, 상표권, 저작권, 또는 기타 지적 소유권 등에 대한 어떠한 사용권도 허여하지 않습니다.
Microsoft, ActiveX, Visual Basic, Windows 및 Windows NT는 미국 및 기타 국가에서 Microsoft Corporation의 등록 상표 또는 상표입니다.
여기에 인용된 실제 회사와 제품 이름은 해당 소유자의 상표일 수 있습니다.