nvarchar멀티 바이트 문자 만 지원합니까? 그렇다면 실제로 스토리지 문제 이외의 다른 점이 varchars있습니까?
답변:
nvarchar열은 유니 코드 데이터를 저장할 수있다. varchar열은 8 비트의 코드 페이지로 제한된다. 일부 사람들은 varchar공간을 덜 차지하기 때문에 사용해야 한다고 생각합니다 . 나는 이것이 정답이 아니라고 생각합니다. 코드 페이지 비 호환성은 고통스럽고 유니 코드는 코드 페이지 문제를 치료합니다. 요즈음 디스크와 메모리가 저렴하기 때문에 더 이상 코드 페이지로 시간을 낭비 할 이유가 없습니다.
모든 최신 운영 체제 및 개발 플랫폼은 내부적으로 유니 코드를 사용합니다. nvarchar대신에 를 사용 varchar하면 데이터베이스에서 읽거나 데이터베이스에 쓸 때마다 인코딩 변환을 피할 수 있습니다. 변환에는 시간이 걸리고 오류가 발생하기 쉽습니다. 전환 오류 복구는 사소한 문제가 아닙니다.
ASCII 만 사용하는 응용 프로그램과 인터페이스하는 경우 데이터베이스에서 유니 코드를 사용하는 것이 좋습니다. OS 및 데이터베이스 데이터 정렬 알고리즘은 유니 코드에서 더 잘 작동합니다. 유니 코드는 다른 시스템 과 인터페이스 할 때 변환 문제를 피 합니다. 그리고 당신은 미래를 준비 할 것입니다. 또한 완전한 유니 코드 스토리지의 이점을 누리면서도 유지 관리해야하는 레거시 시스템에 대해 데이터가 7 비트 ASCII로 제한되어 있는지 항상 확인할 수 있습니다.
varchar : 가변 길이의 비 유니 코드 문자 데이터. 데이터베이스 데이터 정렬에 따라 데이터가 저장된 코드 페이지가 결정됩니다.
nvarchar : 가변 길이 유니 코드 문자 데이터. 비교를 위해 데이터베이스 데이터 정렬에 따라 다릅니다.
이 지식으로 무장 한 경우 입력 데이터와 일치하는 것을 사용하십시오 (ASCII v. Unicode).
float로 int하고, 가고는 "잘 확인 소수가 실종." 하지마
나는 항상 nvarchar를 사용하여 내가 만들고있는 모든 것이 내가 던지는 모든 데이터를 견딜 수있게합니다. nvarchar를 사용했기 때문에 CMS 시스템이 실수로 중국어를 수행합니다. 요즘 새로운 응용 프로그램은 실제로 필요한 공간의 양에 관심을 가져서는 안됩니다.
"never"적어도 기술적 으로 인용 부호를 사용하여 모순의 위험을 제거했다고 생각합니다 .
Oracle 설치 방법에 따라 다릅니다. 설치 과정에서 NLS_CHARACTERSET 옵션이 설정됩니다. 쿼리에서 찾을 수 있습니다 SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'.
NLS_CHARACTERSET이 UTF8과 같은 유니 코드 인코딩 인 경우 좋습니다. VARCHAR과 NVARCHAR 사용은 거의 동일합니다. 지금은 그만하세요. 그렇지 않으면 또는 Oracle 문자 세트를 제어 할 수없는 경우 계속 읽으십시오.
VARCHAR — 데이터는 NLS_CHARACTERSET 인코딩에 저장됩니다. 동일한 서버에 다른 데이터베이스 인스턴스가있는 경우 이들에 의해 제한 될 수 있습니다. 설정을 공유해야하기 때문에 그 반대도 마찬가지입니다. 이러한 필드는 해당 문자 세트를 사용하여 인코딩 할 수있는 모든 데이터를 저장할 수 있으며 그 밖의 다른 것은 없습니다 . 예를 들어 문자 집합이 MS-1252 인 경우 영어 문자, 소수의 악센트 부호 문자 및 기타 문자 (예 : € 및 —)와 같은 문자 만 저장할 수 있습니다. 응용 프로그램은 일부 지역에서만 유용하며 세계 어느 곳에서도 작동 할 수 없습니다. 이러한 이유로, 그것은 나쁜 생각으로 간주됩니다.
NVARCHAR — 데이터는 유니 코드 인코딩으로 저장됩니다. 모든 언어가 지원됩니다. 좋은 아이디어.
저장 공간은 어떻습니까? VARCHAR은 문자 세트 / 인코딩이 특정 로케일에 맞게 사용자 정의 설계 되었기 때문에 일반적으로 효율적입니다. NVARCHAR 필드는 NLS 설정에 따라 충분히 UTF-8 또는 UTF-16 인코딩으로 저장됩니다. UTF-8은 아시아 언어를 계속 지원하면서 "서양"언어에 매우 효율적입니다. UTF-16은 "서양"언어를 계속 지원하면서 아시아 언어에 매우 효율적입니다. 스토리지 공간이 염려되면 Oracle에서 UTF-8 또는 UTF-16을 적절히 사용하도록 NLS 설정을 선택하십시오.
처리 속도는 어떻습니까? 대부분의 새로운 코딩 플랫폼은 기본적으로 유니 코드 (Java, .NET, 심지어 몇 년 전의 C ++ std :: wstring!)를 사용하므로 데이터베이스 필드가 VARCHAR 인 경우 Oracle은 모든 읽기 또는 쓰기에서 문자 세트 간 변환을 강제하지 않습니다. NVARCHAR을 사용하면 변환을 피할 수 있습니다.
결론 : NVARCHAR을 사용하십시오! 제한 사항과 종속성을 피하고 저장 공간에 적합하며 일반적으로 성능에도 가장 좋습니다.
내 두 센트
올바른 데이터 유형을 사용하지 않으면 인덱스가 실패 할 수 있습니다
. SQL Server의 경우 : VARCHAR 열에 대한 인덱스가 있고 유니 코드 문자열을 나타내는 경우 SQL Server는 인덱스를 사용하지 않습니다. SmallInt를 포함하는 인덱스 열에 BigInt를 제공 할 때도 마찬가지입니다. BigInt가 SmallInt가되기에 충분히 작더라도 SQL Server는 인덱스를 사용할 수 없습니다. 다른 방법으로는이 문제가 없습니다 (인덱스 BigInt 및 NVARCHAR 열에 SmallInt 또는 Ansi-Code를 제공하는 경우).
데이터 유형은 DBMS (데이터베이스 관리 시스템)마다 다를 수 있습니다.
모든 데이터베이스의 데이터 유형이 약간 다르며 VARCHAR이 모든 곳에서 동일한 것을 의미하지는 않습니다. SQL Server에는 VARCHAR 및 NVARCHAR이 있지만 Apache / Derby 데이터베이스에는 VARCHAR 만 있고 VARCHAR은 유니 코드입니다.
주로 nvarchar 는 유니 코드 문자를 저장 하고 varchar 는 유니 코드가 아닌 문자를 저장합니다.
"Unicodes"는 아랍어, 히브리어, 중국어, 일본어와 같은 다른 많은 언어의 문자를 단일 문자 세트로 인코딩 할 수있는 16 비트 문자 인코딩 체계를 의미합니다.
즉, 유니 코드는 문자 당 2 바이트를 사용하여 저장하고 비유 니코 드는 문자 당 1 바이트 만 사용하여 저장합니다. 이는 유니 코드가 아닌 유니 코드에 비해 저장하는 데 두 배의 용량이 필요하다는 것을 의미합니다.
NVARCHAR유니 코드를 저장 하지만 데이터 정렬을 사용 VARCHAR하여 현지 언어의 데이터를 사용 하고 저장할 수도 있습니다.
다음 시나리오를 상상해보십시오.
DB의 데이터 정렬은 페르시아어이며 VARCHAR(10)데이터 유형에 'علی'(Als의 페르시아어 쓰기)와 같은 값을 저장합니다 . 문제가 없으며 DBMS는 3 바이트 만 사용하여 저장합니다.
그러나 데이터를 다른 데이터베이스로 전송하고 올바른 결과를 보려면 대상 데이터베이스는이 예에서 페르시아인 대상과 동일한 데이터 정렬을 가져야합니다.
대상 데이터 정렬이 다른 경우 대상 데이터베이스에 물음표 (?)가 표시됩니다.
마지막으로, 현지 언어를 사용하기 위해 거대한 데이터베이스를 사용하는 경우 공간을 너무 많이 사용하는 대신 위치를 사용하는 것이 좋습니다.
디자인이 다를 수 있다고 생각합니다. 작업 환경에 따라 다릅니다.
나는 대답을 보았고 더 이상 공간이 문제가되지 않기 때문에 많은 사람들이 nvarcharover 을 사용하는 것이 좋습니다 varchar. 따라서 여분의 저장 공간을 거의 사용하지 않기 위해 유니 코드를 활성화하는 데 아무런 해가 없습니다. 글쎄, 이것은 열에 색인을 적용하려는 경우 항상 사실이 아닙니다. SQL Server는 인덱싱 할 수있는 필드 크기가 900 바이트로 제한되어 있습니다. 따라서가있는 경우 varchar(900)색인을 생성 할 수는 있지만 색인을 생성 할 수는 없습니다 varchar(901). 을 사용하면 nvarchar문자 수가 반으로 줄어 최대 인덱싱 할 수 있습니다 nvarchar(450). 따라서 필요하지 않다고 확신하는 경우 nvarchar사용하지 않는 것이 좋습니다.
일반적으로 데이터베이스에서는 항상 확장 할 수 있으므로 필요한 크기를 유지하는 것이 좋습니다. 예를 들어, 직장 동료는 nvarchar(max)스토리지에 전혀 문제가 없으므로 컬럼 사용 에 아무런 해가 없다고 생각했습니다 . 나중에이 열에 인덱스를 적용하려고 할 때 SQL Server는이를 거부했습니다. 그러나 그가 짝수로 시작했다면, varchar(5)문제를 해결하기 위해 현장 마이그레이션 계획을 수행해야하는 문제없이 나중에 필요한 것으로 확장 할 수있었습니다.
단일 바이트를 사용하여 문자를 저장하는 경우 256 개의 가능한 조합이 있으므로 256 개의 다른 문자를 저장할 수 있습니다. 데이터 정렬은 문자와 문자를 비교하고 정렬하는 규칙을 정의하는 패턴입니다.
Latin1 (ANSI) 인 1252가 가장 일반적입니다. 1 바이트 문자 세트도 많은 언어에서 사용하는 모든 문자를 저장하기에 부적절합니다. 예를 들어 일부 아시아 언어에는 수천 개의 문자가 있으므로 문자 당 2 바이트를 사용해야합니다.
네트워크에서 여러 코드 페이지를 사용하는 시스템을 사용하면 통신 관리가 어려워집니다. 표준화를 위해 ISO 및 유니 코드 컨소시엄에 유니 코드가 도입되었습니다 . 유니 코드는 2 바이트를 사용하여 각 문자를 저장합니다. 즉 65,536 개의 다른 문자를 정의 할 수 있으므로 거의 모든 문자를 유니 코드로 덮을 수 있습니다. 두 대의 컴퓨터가 유니 코드를 사용하는 경우 모든 기호가 동일한 방식으로 표시되며 변환이 필요하지 않습니다. 이것이 유니 코드의 기본 개념입니다.
SQL Server에는 두 가지 범주의 문자 데이터 유형이 있습니다.
여러 국가의 문자 데이터를 저장해야하는 경우 항상 유니 코드를 사용하십시오.
나는 (내가 아마 메모 대신에 자신을 열어 갈거야 실현!) 여기에서 말해야한다, 그러나 확실하게 유일한 시간 때 NVARCHAR실제로 더 (통지가 유용 더 있다!) 이상의 VARCHAR경우 모두에 정렬의 모든 종속 시스템과 데이터베이스 자체 내에서 동일합니까? 그렇지 않은 경우 데이터 정렬 변환이 어쨌든 발생해야하므로 VARCHAR만큼 가능합니다 NVARCHAR.
여기에 추가하기 위해 SQL Server (2012 이전) 와 같은 일부 데이터베이스 시스템 의 페이지 크기는 약 1입니다. 8K. 따라서 검색 가능한 데이터를 a TEXT또는 NTEXT필드 와 같이 저장하지 않으려 VARCHAR는 경우 8k의 전체 공간 을 제공하는 반면 NVARCHAR4k 만 제공합니다 (바이트의 두 배, 공간의 두 배).
요약하자면 두 가지 중 하나의 사용이 다음에 의존한다고 가정합니다.
Sql Server VARCHAR과 NVARCHAR 데이터 형식의 차이점을 따르십시오 . 여기에서는 매우 설명적인 방식으로 볼 수 있습니다.
일반적으로 nvarchar는 데이터를 유니 코드로 저장하므로 데이터 열에 다국어 데이터 (둘 이상의 언어)를 저장하려면 N 변형이 필요합니다.
와의 주요 차이점은 다음 Varchar(n)과 nvarchar(n)같습니다.
Varchar(가변 길이, 비 유니 코드 문자 데이터) 크기는 최대 8000입니다. 1. 가변 길이 데이터 유형입니다.
비 유니 코드 문자를 저장하는 데 사용
각 문자에 대해 1 바이트의 공간을 차지합니다.
Nvarchar: 가변 길이의 유니 코드 문자 데이터.
1. 가변 길이 데이터 타입
2. 유니 코드 문자를 저장하는 데 사용됩니다.
~ 47000 명성 점수를 가진 Jeffrey L Whitledge는 nvarchar의 사용을 권장합니다
평판 점수가 ~ 33200 인 Solomon Rutzky는 다음을 권장합니다. NVARCHAR을 항상 사용하지 마십시오. 그것은 매우 위험하고 종종 비용이 많이 드는 태도 / 접근법입니다.
varchar와 nvarchar SQL Server 데이터 형식의 주요 성능 차이는 무엇입니까?
https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4
높은 명성을 가진 두 사람 모두 학습 SQL Server 데이터베이스 개발자는 무엇을 선택합니까?
선택에 일관성이없는 경우 성능 문제에 대한 답변 및 의견에 많은 경고가 있습니다.
성능에 대한 의견 pro / con nvarchar가 있습니다.
성능에 대한 의견 pro / con varchar가 있습니다.
수백 개의 열이있는 테이블에 대한 특별한 요구 사항이 있습니다.
SQL * server 2012의 8060 바이트 테이블 레코드 크기 제한에 근접하지 않도록 varchar를 선택하고 있습니다.
나를 위해 nvarchar를 사용하면이 8060 바이트 제한을 초과합니다.
또한 관련 코드 테이블의 데이터 유형을 기본 중앙 테이블의 데이터 유형과 일치시켜야한다고 생각합니다.
나는 경험이 풍부한 데이터베이스 개발자에 의해 사우스 오스트레일리아 정부 의이 작업 장소에서 varchar 열을 사용하는 것을 보았습니다. 예상 데이터 행 볼륨이이 결정의 일부가 될 수 있습니다.
nvarchar유니 코드 문자도 허용 varchar하기 때문에 코드 오류를 없애기 위해 (타입 불일치)하기 위해 비교하는 것이 안전합니다 nvarchar. whereSQL Server 쿼리에서 조건을 사용할 때 =연산자를 사용하는 경우 몇 번 오류가 발생합니다. 가능한 이유는 매핑 열이로 정의되어 있기 때문입니다 varchar. 우리 nvarchar가이 문제 에서 그것을 정의하면 내 일은 일어나지 않습니다. 여전히 우리는 varchar이 문제를 고수 하고 피하기 LIKE보다는 키워드를 사용하는 것이 좋습니다 =.