nvarchar
가 멀티바이트 문자를 지원하기 때문입니까? varchars
를 사용하는 것에 대한 포인트가 실제로 있습니까?
질문자 :stimms
nvarchar
열은 모든 유니코드 데이터를 저장할 수 있습니다. varchar
열은 8비트 코드 페이지로 제한됩니다. 어떤 사람들은 varchar
가 공간을 덜 차지하기 때문에 사용해야 한다고 생각합니다. 나는 이것이 정답이 아니라고 믿는다. 코드 페이지 비호환성은 고통스럽고 유니코드는 코드 페이지 문제에 대한 치료법입니다. 오늘날 저렴한 디스크와 메모리를 사용하면 더 이상 코드 페이지를 만지작거리며 시간을 낭비할 이유가 없습니다.
모든 최신 운영 체제 및 개발 플랫폼은 내부적으로 유니코드를 사용합니다. varchar
대신 nvarchar
를 사용하면 데이터베이스에서 읽거나 쓸 때마다 인코딩 변환을 수행하지 않아도 됩니다. 변환에는 시간이 걸리고 오류가 발생하기 쉽습니다. 그리고 변환 오류로부터의 복구는 사소한 문제가 아닙니다.
ASCII만 사용하는 응용 프로그램과 인터페이스하는 경우에도 데이터베이스에서 유니코드를 사용하는 것이 좋습니다. OS 및 데이터베이스 데이터 정렬 알고리즘은 유니코드에서 더 잘 작동합니다. 유니코드는 다른 시스템과 인터페이스할 때 변환 문제를 방지합니다. 그리고 미래를 준비하게 될 것입니다. 또한 전체 유니코드 스토리지의 이점을 누리면서도 유지 관리해야 하는 레거시 시스템에 대해 데이터가 7비트 ASCII로 제한되어 있는지 항상 확인할 수 있습니다.
Jeffrey L Whitledge
varchar : 가변 길이의 비유니코드 문자 데이터입니다. 데이터베이스 데이터 정렬은 데이터가 저장되는 코드 페이지를 결정합니다.
nvarchar : 가변 길이 유니코드 문자 데이터입니다. 비교를 위해 데이터베이스 데이터 정렬에 따라 다릅니다.
이 지식으로 무장하여 입력 데이터와 일치하는 것을 사용하십시오(ASCII v. Unicode).
user7116
나는 항상 nvarchar를 사용합니다. 내가 구축하는 것이 무엇이든 내가 던진 거의 모든 데이터를 견딜 수 있기 때문입니다. 내 CMS 시스템은 nvarchar를 사용했기 때문에 실수로 중국어를 수행합니다. 요즈음, 모든 새로운 응용 프로그램은 필요한 공간의 양에 대해 크게 신경쓰지 않아야 합니다.
tags2k
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은 여전히 "서양" 언어를 지원하면서 아시아 언어에 대해 매우 효율적입니다. 저장 공간이 염려되는 경우 NLS 설정을 선택하여 Oracle이 적절하게 UTF-8 또는 UTF-16을 사용하도록 하십시오.
처리 속도는 어떻습니까? 대부분의 새로운 코딩 플랫폼은 기본적으로 유니코드를 사용합니다(Java, .NET, 심지어 몇 년 전의 C++ std::wstring!). 따라서 데이터베이스 필드가 VARCHAR인 경우 Oracle이 모든 읽기 또는 쓰기에서 문자 세트 간에 변환하도록 강제하지만 그다지 좋지는 않습니다. NVARCHAR를 사용하면 변환을 피할 수 있습니다.
결론: NVARCHAR를 사용하십시오! 제한 및 종속성을 피하고 저장 공간에 적합하며 일반적으로 성능에도 가장 좋습니다.
Jeremy Frank
nvarchar는 데이터를 유니코드로 저장하므로 데이터 열에 다국어 데이터(둘 이상의 언어)를 저장하려면 N 변형이 필요합니다.
albertein
내 두 센트
올바른 데이터 유형을 사용하지 않으면 인덱스가 실패할 수 있습니다.
SQL Server에서: VARCHAR 열에 대한 인덱스가 있고 유니코드 문자열을 제공하면 SQL Server는 인덱스를 사용하지 않습니다. SmallInt를 포함하는 인덱스 열에 BigInt를 제시할 때도 같은 일이 발생합니다. BigInt가 SmallInt가 될 만큼 작더라도 SQL Server는 인덱스를 사용할 수 없습니다. 다른 방법으로는 이 문제가 없습니다(SmallInt 또는 Ansi-Code를 인덱싱된 BigInt 또는 NVARCHAR 열에 제공할 때).데이터 유형은 DBMS(DataBase Management System)마다 다를 수 있습니다.
모든 데이터베이스는 약간 다른 데이터 유형을 가지고 있으며 VARCHAR이 모든 곳에서 동일한 것을 의미하지는 않습니다. SQL Server에는 VARCHAR 및 NVARCHAR이 있는 반면 Apache/Derby 데이터베이스에는 VARCHAR만 있고 VARCHAR은 유니코드로 되어 있습니다.
incomudro
주로 nvarchar 는 유니코드 문자를 저장하고 varchar 는 유니코드가 아닌 문자를 저장합니다.
"유니코드"는 아랍어, 히브리어, 중국어, 일본어와 같은 다른 많은 언어의 문자를 단일 문자 세트로 인코딩할 수 있는 16비트 문자 인코딩 체계를 의미합니다.
즉, 유니코드는 문자당 2바이트를 사용하여 저장하고 비유니코드는 문자당 1바이트만 사용하여 저장합니다. 즉, 유니코드는 비유니코드에 비해 두 배의 저장 용량이 필요합니다.
ranjit pawar
네가 옳아. nvarchar
는 유니코드 데이터를 varchar
는 1바이트 문자 데이터를 저장합니다. 이미 언급한 스토리지 차이( nvarchar
varchar
두 배의 스토리지 공간 필요 varchar
nvarchar
를 선호하는 주된 이유는 국제화(즉, 문자열을 다른 언어로 저장)입니다.
Mike Spross
나는 그것이 달려 있다고 말할 것입니다.
OS가 유니코드로 작동하고(현재 모든 Windows 시스템과 같이) 언어가 기본적으로 유니코드를 지원하는 데스크톱 애플리케이션을 개발하는 경우(기본 문자열은 Java 또는 C#에서와 같이 유니코드임) nvarchar로 이동합니다.
문자열이 UTF-8로 입력되고 언어가 여전히 기본적으로 유니코드(버전 5.x)를 지원하지 않는 PHP인 웹 애플리케이션을 개발하는 경우 varchar가 더 나은 선택이 될 것입니다.
sleepy012
Varchar(n)
과 nvarchar(n)
의 주요 차이점은 다음과 같습니다.
Varchar
(가변 길이, 비유니코드 문자 데이터) 크기는 최대 8000입니다.
- 가변 길이 데이터 유형입니다.
- 비유니코드 문자를 저장하는 데 사용
- 각 문자에 대해 1바이트의 공간을 차지합니다.
Nvarchar
: 가변 길이 유니코드 문자 데이터입니다.
- 가변 길이 데이터 유형입니다.
- 유니코드 문자를 저장하는 데 사용됩니다.
- 데이터는 유니코드 인코딩으로 저장됩니다. 모든 언어가 지원됩니다. (예를 들어 언어 아랍어, 독일어, 힌디어 등)
Debendra Dash
nVarchar는 유니코드 문자를 저장하는 데 도움이 됩니다. 현지화 된 데이터를 저장하려는 경우 갈 방법입니다.
Vijesh VP
NVARCHAR
이 유니코드를 저장하지만 VARCHAR
를 사용하고 현지 언어로 데이터를 저장할 수도 있다는 점을 고려해야 합니다.
다음 시나리오를 상상해 보십시오.
VARCHAR(10)
데이터 유형에 'علی'(Ali의 페르시아어 쓰기)과 같은 값을 저장합니다. 문제가 없으며 DBMS는 3바이트만 사용하여 저장합니다.
그러나 데이터를 다른 데이터베이스로 전송하고 올바른 결과를 보려면 대상 데이터베이스가 이 예에서 페르시아어인 대상과 동일한 데이터 정렬을 가져야 합니다.
대상 데이터 정렬이 다른 경우 대상 데이터베이스에 물음표(?)가 표시됩니다.
마지막으로 현지 언어를 사용하는 거대한 데이터베이스를 사용하는 경우 공간을 너무 많이 사용하는 대신 위치를 사용하는 것이 좋습니다.
디자인이 다를 수 있다고 생각합니다. 작업하는 환경에 따라 다릅니다.
Ali Elmi
varchar
보다 nvarchar
를 사용하도록 권장하는 것 같습니다. 공간이 더 이상 문제가 되지 않기 때문에 약간의 추가 저장 공간을 위해 유니코드를 활성화해도 해가 없기 때문입니다. 열에 인덱스를 적용하려는 경우 항상 그렇지는 않습니다. SQL Server는 인덱싱할 수 있는 필드 크기가 900바이트로 제한됩니다. 따라서 varchar(900)
이 있는 경우 여전히 인덱싱할 수 있지만 varchar(901)
은 할 수 없습니다. nvarchar
사용하면 문자 수가 절반으로 줄어들므로 최대 nvarchar(450)
까지 인덱싱할 수 있습니다. nvarchar
가 필요하지 않다고 확신한다면 사용하지 않는 것이 좋습니다.
일반적으로 데이터베이스에서는 항상 확장할 수 있으므로 필요한 크기를 유지하는 것이 좋습니다. 예를 들어, 직장 동료는 스토리지에 전혀 문제가 없기 때문에 열에 nvarchar(max)
를 사용하는 것이 해가 없다고 생각한 적이 있습니다. 나중에 이 열에 인덱스를 적용하려고 했을 때 SQL Server에서 이를 거부했습니다. 그러나 그가 varchar(5)
시작했다면 이 문제를 해결하기 위해 현장 마이그레이션 계획을 수행해야 하는 문제 없이 나중에 필요한 것으로 간단히 확장할 수 있었습니다.
Rafid
단일 바이트를 사용하여 문자를 저장하는 경우 256개의 가능한 조합이 있으므로 256개의 다른 문자를 저장할 수 있습니다. 데이터 정렬은 문자와 문자를 비교 및 정렬하는 규칙을 정의하는 패턴입니다.
라틴1(ANSI)인 1252가 가장 일반적입니다. 1바이트 문자 집합은 또한 많은 언어에서 사용되는 모든 문자를 저장하기에 부적합합니다. 예를 들어 일부 아시아 언어에는 수천 개의 문자가 있으므로 문자당 2바이트를 사용해야 합니다.
유니코드 표준
여러 코드 페이지를 사용하는 시스템이 네트워크에서 사용되면 통신 관리가 어려워집니다. 표준화를 위해 ISO 및 유니코드 컨소시엄은 유니코드를 도입했습니다. 유니코드는 2바이트를 사용하여 각 문자를 저장합니다. 즉, 65,536개의 다른 문자를 정의할 수 있으므로 거의 모든 문자를 유니코드로 덮을 수 있습니다. 두 대의 컴퓨터가 유니코드를 사용하는 경우 모든 기호는 동일한 방식으로 표시되며 변환이 필요하지 않습니다. 이것이 유니코드의 기본 개념입니다.
SQL Server에는 두 가지 범주의 문자 데이터 유형이 있습니다.
- 비유니코드(char, varchar 및 text)
- 유니코드(nchar, nvarchar 및 ntext)
여러 국가의 문자 데이터를 저장해야 하는 경우 항상 유니코드를 사용하십시오.
Jithin Shaji
나는 여기에서 말해야 한다(나는 아마 슬레이트까지 나 자신을 열게 될 것이라는 것을 깨달았다!), 그러나 확실히 NVARCHAR
가 실제로 VARCHAR
보다 더 유용한 유일한 경우(더 많은 것을 주목하라!)는 모든 데이터 정렬이 모든 종속 시스템과 데이터베이스 자체에서 동일합니다...? 그렇지 않다면 어쨌든 데이터 정렬 변환이 일어나야 하므로 VARCHAR
NVARCHAR
만큼 실행 가능하게 만듭니다.
여기에 추가하기 위해 SQL Server(2012 이전) 와 같은 일부 데이터베이스 시스템의 페이지 크기는 약 8K TEXT
또는 NTEXT
필드와 같은 항목에 보관되지 않은 검색 가능한 데이터를 저장하려는 경우 VARCHAR
은 전체 8k의 공간을 NVARCHAR
는 4k(바이트의 두 배, 공간의 두 배)만 제공합니다.
요약하자면 둘 중 하나의 사용은 다음에 의존한다고 가정합니다.
- 프로젝트 또는 컨텍스트
- 하부 구조
- 데이터베이스 시스템
Paul
SQL Server VARCHAR 및 NVARCHAR 데이터 유형의 차이점을 따르십시오. 여기에서 매우 설명적인 방식으로 볼 수 있습니다.
일반적으로 nvarchar는 데이터를 유니코드로 저장하므로 데이터 열에 다국어 데이터(둘 이상의 언어)를 저장하려면 N 변형이 필요합니다.
Pradeep Kesharwani
평판 점수가 47000인 Jeffrey L Whitledge는 nvarchar 사용을 권장합니다.
~33200의 평판 점수를 가진 솔로몬 루츠키는 다음을 권장합니다. 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 열을 사용하는 것을 보았습니다. 여기서 테이블 행 수가 수백만 이상이 될 것입니다. 테이블), 따라서 예상되는 데이터 행 볼륨이 이 결정의 일부가 될 수 있습니다.
Allan F
varchar
는 non-Unicode characters
에만 nvarchar
unicode
및 non-unicode
문자 모두에 사용됩니다. 그들 사이의 다른 차이점은 다음과 같습니다.
VARCHAR 대 NVARCHAR
바르차르 | NVARCHAR | |
---|---|---|
문자 데이터 유형 | 가변 길이, 비유니코드 문자 | 가변 길이, 유니코드 및 일본어, 한국어 및 중국어와 같은 비유니코드 문자. |
최대 길이 | 최대 8,000 characters | 최대 4,000 characters |
문자 크기 | 문자당 1 byte | 유니코드/비유니코드 문자당 2 bytes |
스토리지 크기 | 실제 길이(바이트) | 실제 길이의 2배(바이트) |
용법 | 데이터 길이가 가변 또는 가변 길이 열이고 실제 데이터가 항상 용량보다 적은 경우에 사용됩니다. | 저장 공간만 있기 때문에 일본어 한자나 한글과 같은 유니코드 지원이 필요한 경우에만 사용합니다. |
Amar Anondo
SQL Server 2019 이후 varchar 열은 UTF-8 인코딩을 지원합니다.
따라서 이제부터 차이는 크기입니다.
속도의 차이로 변환되는 데이터베이스 시스템에서.
더 적은 크기 = 더 적은 IO + 더 적은 메모리 = 일반적으로 더 빠른 속도. 숫자에 대해서는 위의 기사를 읽으십시오.
지금부터 UTF8의 varchar로 이동하십시오!
2048 - 16383 및 16384 - 65535 범위의 문자가 포함된 데이터의 비율 이 높은 경우에만 측정해야 합니다.
Alexander Bartosh
nvarchar
비교 안전하게 사용할 수 varchar
때문에 우리의 코드 오류 무료 (유형 불일치)를 만들기 위해 nvarchar
유니 코드 문자도 있습니다. SQL Server 쿼리에서 where
조건을 사용할 때 =
연산자를 사용하면 몇 번 오류가 발생합니다. 이에 대한 가능한 이유는 매핑 열이 varchar
에서 정의되기 때문입니다. nvarchar
에서 정의하면 이 문제가 발생하지 않습니다. 여전히 우리는 varchar
를 고수하고 이 문제를 피합니다. =
LIKE
키워드를 사용하는 것이 좋습니다.
Rinoy Ashokan
출처 : http:www.stackoverflow.com/questions/144283/what-is-the-difference-between-varchar-and-nvarchar
'etc. > StackOverFlow' 카테고리의 다른 글
init으로 생성된 git 저장소를 완전히 삭제하는 방법은 무엇입니까? (0) | 2022.02.24 |
---|---|
모나드란? (0) | 2022.02.24 |
다른 스레드에서 GUI를 어떻게 업데이트합니까? (0) | 2022.02.24 |
UNION과 UNION ALL의 차이점은 무엇입니까? (0) | 2022.02.19 |
문자열이 유효한 숫자인지 확인하는 JavaScript의 (내장) 방법 (0) | 2022.02.19 |