SQL Server에서 VARCHAR / CHAR 대신 NVARCHAR / NCHAR을 언제 사용해야합니까?

SQL Server에서 VARCHAR / CHAR 대신 NVARCHAR / NCHAR을 언제 사용해야합니까?

---

유니 코드 유형을 사용해야하는 경우 규칙이 있습니까?

대부분의 유럽 언어 (독일어, 이탈리아어, 영어, ...)가 VARCHAR 열의 동일한 데이터베이스에서 괜찮다는 것을 확인했습니다.

나는 다음과 같은 것을 찾고 있습니다.

1. 중국어가있는 경우-> NVARCHAR 사용
2. 독일어와 아랍어가있는 경우-> NVARCHAR 사용

서버 / 데이터베이스의 데이터 정렬은 어떻습니까?

여기에 제안 된 것처럼 항상 NVARCHAR을 사용하고 싶지 않습니다. varchar와 nvarchar SQL Server 데이터 형식의 주요 성능 차이는 무엇입니까?

---

NVARCHAR을 사용하려는 실제 이유 는 동일한 열에 다른 언어가있는 경우, 디코딩없이 T-SQL의 열을 처리해야하거나, SSMS에서 "기본적으로"데이터를 볼 수 있기를 원하거나 원하는 경우 유니 코드로 표준화합니다.

데이터베이스를 멍청한 저장소로 취급하면 VARCHAR (예 : UTF-8)에 넓은 문자열과 다양한 (가변 길이 포함) 인코딩을 완벽하게 저장할 수 있습니다. 특히 코드 페이지가 다른 행에 대해 다른 경우 인코딩 및 디코딩을 시도 할 때 문제가 발생합니다. 또한 SQL Server가 (잠재적으로 가변적 인) 인코딩 된 열에 대해 T-SQL 내에서 쿼리 할 목적으로 데이터를 쉽게 처리 할 수 ​​없음을 의미합니다.

NVARCHAR를 사용하면이 모든 것을 피할 수 있습니다.

비교적 제약이없는 사용자 입력 데이터가있는 열에 대해 NVARCHAR을 권장합니다.

일반적으로 표준 또는 법률 또는 규칙에 의해 정의되고 제한되는 자연 키 (예 : 차량 번호판, SSN, 일련 번호, 서비스 태그, 주문 번호, 공항 호출 부호 등) 인 모든 열에 대해 VARCHAR을 권장합니다. 또한 사용자가 입력하고 매우 제한적인 (전화 번호와 같은) 코드 (ACTIVE / CLOSED, Y / N, M / F, M / S / D / W 등)에 대한 VARCHAR입니다. NVARCHAR을 사용할 이유가 전혀 없습니다.

따라서 간단한 규칙 :

제한되는 경우 VARCHAR 그렇지 않은 경우 NVARCHAR

---

여러 언어를 저장해야 할 때마다 NVARCHAR을 사용해야합니다. 나는 당신이 그것을 아시아 언어로 사용해야한다고 믿지만 그것을 인용하지 마십시오.

예를 들어 러시아어를 가져 와서 varchar에 저장하면 문제가 있습니다. 올바른 코드 페이지를 정의하는 한 괜찮습니다. 그러나 기본 영어 SQL 설치를 사용한다고 가정하면 러시아어 문자가 올바르게 처리되지 않습니다. NVARCHAR ()을 사용하는 경우 제대로 처리됩니다.

편집하다

알겠습니다. MSDN 과 maybee를 구체적으로 인용하겠습니다. 하지만 varcar 열에 하나 이상의 코드 페이지를 저장하고 싶지는 않지만 할 수는 없습니다.

char, varchar, varchar (max) 또는 text 데이터 유형에 저장된 텍스트 데이터를 처리 할 때 고려해야 할 가장 중요한 제한 사항은 단일 코드 페이지의 정보 만 시스템에서 유효성을 검사 할 수 있다는 것입니다. (여러 코드 페이지의 데이터를 저장할 수 있지만 권장되지는 않습니다.) 데이터의 유효성을 검사하고 저장하는 데 사용되는 정확한 코드 페이지는 열의 데이터 정렬에 따라 다릅니다. 열 수준 데이터 정렬이 정의되지 않은 경우 데이터베이스의 데이터 정렬이 사용됩니다. 주어진 열에 사용되는 코드 페이지를 확인하려면 다음 코드 예제와 같이 COLLATIONPROPERTY 함수를 사용할 수 있습니다.

다음은 더 있습니다.

이 예는 그루지야 어 및 힌디어와 같은 많은 로케일에 유니 코드 전용 데이터 정렬이므로 코드 페이지가 없다는 사실을 보여줍니다. 이러한 데이터 정렬은 char, varchar 또는 text 데이터 유형을 사용하는 열에 적합하지 않습니다.

따라서 그루지야 어 또는 힌디어는 실제로 nvarchar로 저장해야합니다. 아랍어도 문제입니다.

발생할 수있는 또 다른 문제는 지원하려는 모든 문자가 코드 페이지에 포함되어 있지 않을 때 데이터를 저장할 수 없다는 것입니다. 대부분의 경우 Windows는 특정 코드 페이지를 "최적의"코드 페이지로 간주합니다. 즉, 모든 텍스트를 처리하기 위해 코드 페이지에 의존 할 수 있다는 보장이 없습니다. 그것은 단지 가능한 최고의 것입니다. 이에 대한 예는 아랍어 스크립트입니다. Baluchi, Berber, Farsi, Kashmiri, Kazakh, Kirghiz, Pashto, Sindhi, Uighur, Urdu 등 다양한 언어를 지원합니다. 이러한 모든 언어에는 Windows 코드 페이지 1256에 정의 된 아랍어 언어 이외의 추가 문자가 있습니다. 이러한 추가 문자를 아랍어 데이터 정렬이있는 비 유니 코드 열에 저장하려고하면 문자가 물음표로 변환됩니다.

단일 열에 다른 언어를 저장할 수 있지만 단일 데이터 정렬을 사용하여 정렬 할 수 있지만 유니 코드를 사용할 때 명심해야 할 사항입니다. 라틴 문자를 사용하지만 다른 라틴 언어처럼 정렬되지 않는 일부 언어가 있습니다. 악센트는 이것의 좋은 예입니다. 저는 예를 기억할 수 없지만 Y가 영어 Y처럼 정렬되지 않은 동유럽 언어가있었습니다. 그런 다음 스페인어 사용자가 h 이후에 정렬하려고하는 스페인어 채널이 있습니다.

내면화를 다룰 때 처리해야하는 모든 문제를 모두 포함합니다. 처음부터 유니 코드 문자를 사용하고 추가 변환을 피하고 공백을 차지하는 것이 더 쉽습니다. 따라서 이전에 내 진술.

---

그리스어는 N 열 유형에 UTF-8이 필요합니다 : αβγ;)

---

Josh는 다음과 같이 말합니다. ".... 유니 코드를 사용할 때 명심해야 할 사항은 단일 열에 다른 언어를 저장할 수 있지만 단일 데이터 정렬로만 정렬 할 수 있습니다. 라틴 문자를 사용하지만 다음과 같이 정렬하지 않는 언어가 있습니다. 다른 라틴어입니다. 악센트가 좋은 예입니다. 예를 기억할 수는 없지만 Y가 영어 Y처럼 정렬되지 않은 동유럽 언어가있었습니다. 그러면 스페인어 사용자가 정렬하려고하는 스페인어 채널이 있습니다. h 후에. "

저는 스페인어 원어민이고 "ch"는 문자가 아니라 "c"와 "h"두 개이고 스페인어 알파벳은 다음과 같습니다. abcdefghijklmn ñ opqrstuvwxyz "h"뒤에 "ch"를 기대하지 않고 "i" 알파벳은 ñ 또는 HTML "& ntilde;"를 제외하고 영어와 동일합니다.

알렉스

---

TL; DR;
유니 코드-(nchar, nvarchar 및 ntext)
비 유니 코드-(char, varchar 및 text).

MSDN에서

SQL Server의 데이터 정렬은 데이터에 대한 정렬 규칙, 대 / 소문자 및 악센트 구분 속성을 제공합니다. char 및 varchar와 같은 문자 데이터 유형과 함께 사용되는 데이터 정렬은 해당 데이터 유형에 대해 표시 될 수있는 코드 페이지 및 해당 문자를 지시합니다.

기본 SQL 데이터 정렬 SQL_Latin1_General_CP1_CI_AS을 사용한다고 가정하면 다음 스크립트는 인쇄 VARCHAR된 목록에 표시되지 않는 경우 1 바이트 (총 256 개)를 저장하는 데 1 바이트를 사용하기 때문에 입력 할 수있는 모든 기호를 인쇄해야합니다 NVARCHAR.

declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + '  '+  char(@i)  collate SQL_Latin1_General_CP1_CI_AS 
print cast(@i as varchar(3)) + '  '+ char(@i)  collate Japanese_90_CI_AS  
set @i = @i+1;
end

배열을 일본어로 변경하면 이상한 유럽 문자가 모두 정상으로 바뀌고 일부 기호가 ?표시 로 바뀌는 것을 알 수 있습니다.

Unicode is a standard for mapping code points to characters. Because it is designed to cover all the characters of all the languages of the world, there is no need for different code pages to handle different sets of characters. If you store character data that reflects multiple languages, always use Unicode data types (nchar, nvarchar, and ntext) instead of the non-Unicode data types (char, varchar, and text).

Otherwise your sorting will go weird.

참고URL : https://stackoverflow.com/questions/612430/when-must-we-use-nvarchar-nchar-instead-of-varchar-char-in-sql-server