의 차이점은 무엇입 varchar 및 이며?

Question

그것은 단지 nvarchar 지원 멀티바이트 문자가 있습니까?는 경우,정말 어떤 점을,이외의 다른 우려는 사용을 위한 varchars?

Answer 1

an nvarchar 열은 유니 코드 데이터를 저장할 수 있습니다. ㅏ varchar 열은 8 비트 코드 페지로 제한됩니다. 어떤 사람들은 그렇게 생각합니다 varchar 공간이 적기 때문에 사용해야합니다. 나는 이것이 정답이 아니라고 생각합니다. Codepage 비 호환성은 통증이며, 유니 코드는 코드 피지 문제의 치료법입니다. 요즘 저렴한 디스크와 메모리를 사용하면 더 이상 코드 페이지와 함께 시간을 낭비 할 이유가 없습니다.

모든 최신 운영 체제 및 개발 플랫폼은 내부적으로 유니 코드를 사용합니다. 사용하여 nvarchar 보다는 varchar, 데이터베이스에서 읽거나 쓸 때마다 인코딩 변환을 피할 수 있습니다. 전환에는 시간이 걸리고 오류가 발생하기 쉽습니다. 전환 오류로부터의 복구는 사소한 문제입니다.

ASCII 만 사용하는 응용 프로그램과 인터페이스하는 경우 데이터베이스에서 유니 코드를 사용하는 것이 좋습니다. OS 및 데이터베이스 콜레이션 알고리즘은 유니 코드에서 더 잘 작동합니다. 유니 코드는 인터페이스 할 때 변환 문제를 피합니다 다른 시스템. 그리고 당신은 미래를 준비 할 것입니다. 또한 전체 유니 코드 스토리지의 일부 이점을 누릴 때도 유지해야 할 레거시 시스템에 대해 데이터가 7 비트 ASCII로 제한되어 있음을 항상 확인할 수 있습니다.

Answer 2

바르 차: 가변 길이, 비 unicode 문자 데이터. 데이터베이스 Collation은 데이터를 사용하여 저장된 코드 페이지를 결정합니다.

nvarchar: 가변 길이 유니 코드 문자 데이터. 비교를 위해 데이터베이스 콜레이션에 따라 다릅니다.

이 지식으로 무장하고 입력 데이터 (ASCII v. Unicode)와 일치하는 것을 사용하십시오.

Answer 3

나는 항상 Nvarchar를 사용하여 내가 만들고있는 모든 데이터가 내가 던지는 모든 데이터를 견딜 수있게되므로 항상 사용합니다. NVarchar를 사용했기 때문에 CMS 시스템은 우연히 중국어를 사용합니다. 요즘에는 새로운 응용 프로그램이 실제로 필요한 공간의 양에 관심이 없어야합니다.

Answer 4

Oracle의 설치 방법에 따라 다릅니다. 설치 프로세스 중에 NLS_CHARACTERSET 옵션이 설정됩니다. 쿼리로 찾을 수 있습니다. SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'.

NLS_CHARACTERSET이 UTF8과 같은 유니 코드 인 경우 훌륭합니다. Varchar와 Nvarchar를 사용하는 것은 거의 동일합니다. 지금 독서를 그만두고 그냥 가십시오. 그렇지 않으면 또는 오라클 문자 세트를 제어 할 수없는 경우 계속 읽으십시오.

VARCHAR - 데이터는 NLS_CHARACTERSET 인코딩에 저장됩니다. 동일한 서버에 다른 데이터베이스 인스턴스가있는 경우 이에 의해 제한 될 수 있습니다. 설정을 공유해야하므로 그 반대도 마찬가지입니다. 이러한 필드는 해당 문자 세트를 사용하여 인코딩 할 수있는 데이터를 저장할 수 있으며 다른 것은 없습니다.. 예를 들어 캐릭터 세트가 MS-1252 인 경우 영어 문자, 소수의 악센트 문자 및 기타 (€ 및-)와 같은 문자 만 저장할 수 있습니다. 귀하의 응용 프로그램은 전 세계 어느 곳에서나 운영 할 수없는 몇몇 지역에만 유용 할 것입니다. 이런 이유로, 그것은 나쁜 생각으로 간주됩니다.

NVARCHAR - 데이터는 유니 코드 인코딩에 저장됩니다. 모든 언어는 지원됩니다. 좋은 아이디어.

저장 공간은 어떻습니까? Varchar는 특성 세트 / 인코딩이 특정 로케일에 대해 맞춤형 디자인 되었기 때문에 일반적으로 효율적입니다. Nvarchar Fields는 UTF-8 또는 UTF-16 인코딩에 저장하고 NLS를 아이러니하게 설정합니다. UTF-8은 "서부"언어에 매우 효율적이며 여전히 아시아 언어를 지원합니다. UTF-16은 아시아 언어에 대해 매우 효율적이며 여전히 "서부"언어를 지원합니다. 저장 공간에 대해 우려하는 경우 NLS 설정을 선택하여 Oracle이 UTF-8 또는 UTF-16을 적절하게 사용하게합니다.

처리 속도는 어떻습니까? 대부분의 새로운 코딩 플랫폼은 기본적으로 유니 코드 (Java, .NET, 심지어 C ++ std :: wstring!)를 사용하므로 데이터베이스 필드가 VarChar라면 Oracle은 모든 읽기 또는 쓰기에서 문자 세트 사이를 변환하도록 강요합니다. Nvarchar를 사용하면 변환이 피할 수 있습니다.

결론 : Nvarchar를 사용하십시오! 제한 사항과 종속성을 피하고 저장 공간에 적합하며 일반적으로 성능에도 적합합니다.

Answer 5

Nvarchar는 데이터를 유니 코드로 저장하므로 데이터 열에 다국어 데이터 (둘 이상의 언어)를 저장하려면 n 변형이 필요합니다.

Answer 6

내 두 센트

1. 올바른 데이터 유형을 사용하지 않을 때 인덱스가 실패 할 수 있습니다.
   SQL Server : Varchar 열에 인덱스가 있고 유니 코드 문자열을 제시하면 SQL Server가 인덱스를 사용하지 않습니다. Smallint가 포함 된 인덱스 컬럼에 큰 영향을 줄 때도 같은 일이 발생합니다. Bigint가 Smallint가 될 정도로 작더라도 SQL Server는 인덱스를 사용할 수 없습니다. 주변의 다른 방법에는이 문제가 없습니다 (smallint 또는 ansi-code를 색인화 된 Bigint OT Nvarchar 열에 제공 할 때).

2. 데이터 유형은 DBMS (데이터베이스 관리 시스템)마다 다를 수 있습니다.
   모든 데이터베이스는 약간 다른 데이터 유형을 가지고 있으며 Varchar는 어디에서나 동일하게 의미하지는 않습니다. SQL Server에는 Varchar와 Nvarchar가 있지만 Apache/Derby 데이터베이스에는 Varchar 만 있으며 Varchar는 유니 코드에 있습니다.

Answer 7

주로 nvarchar 유니 코드 문자를 저장합니다 바르 차 비공개 문자를 저장합니다.

"유니 코드"는 아랍어, 히브리어, 중국어, 일본어와 같은 다른 많은 언어의 문자를 단일 문자 세트로 인코딩 할 수있는 16 비트 문자 인코딩 체계를 의미합니다.

즉, 유니 코드는 문자 당 2 바이트를 사용하여 저장하고 비공개는 문자 당 하나의 바이트 만 사용하여 저장합니다. 이는 유니 코드가 비 unicodes에 비해 저장하는 데 이중 용량이 필요하다는 것을 의미합니다.

Answer 8

네가 옳아. nvarchar 유니 코드 데이터를 저장합니다 varchar 단일 바이트 문자 데이터를 저장합니다. 스토리지 차이 외에 (nvarchar 저장 공간의 두 배가 필요합니다 varchar), 이미 언급 한, 선호하는 주된 이유 nvarchar ~ 위에 varchar 국제화 (즉, 다른 언어로 문자열 저장)입니다.

Answer 9

나는 그것이 달라진다고 말할 것이다.

OS가 유니 코드 (모든 현재 Windows 시스템과 같은)에서 작동하는 데스크탑 응용 프로그램을 개발하고 언어는 기본적으로 유니 코드를 지원합니다 (기본 문자열은 Java 또는 C#과 같이 유니 코드입니다).

문자열이 UTF-8으로 들어오는 웹 애플리케이션을 개발하고 언어가 PHP 인 경우 여전히 유니 코드를 기본적으로 지원하지 않는 경우 (버전 5.x) Varchar는 아마도 더 나은 선택 일 것입니다.

Answer 10

Nvarchar는 유니 코드 문자를 저장하는 데 도움이됩니다. 현지화 된 데이터를 저장하려면 갈 길입니다.

Answer 11

는 경우에 하나의 바이트를 저장하는 데 사용되는 캐릭터가 있 256 가능한 조합하여 저장할 수 있습니다 256 다른 자입니다.데이터 정렬 패턴을 정의하는 자는 규칙들은 비교하고 분류되어 있습니다.

1252 는 라틴어 1(ANSI),가장 일반적입니다.단일바이트 문자 집합은 또한 부적절한 모든 문자를 사용하여 여러 언어를 사용할 수 있습니다.예를 들어,일부 아시아 언어 있는 수천 개의 문자,그래서 그들은 사용해야 합 두 바이트별 문자입니다.

유니코드를 표준

할 때 사용하는 시스템에 여러 개의 코드페이지에서 사용되는 네트워크가 관리하기 어려운 커뮤니케이션.하여 표준화한 것,ISO 및 유니코드 컨소시엄 소개 유니코드.유니코드를 사용하여 두 개의 바이트를 저장하는 각 문자입니다.는 65,536 다른 문자 정의 할 수 있습니다,그래서 거의 모든 문자할 수 있으로 덮여 있습니다.는 경우 두 컴퓨터를 사용하는 유니코드,모든 상징으로 표시됩니다 같은 방식으로 변환이 필요하다-이것은 아이디어의 뒤에 있습니다.

SQL 서버는 두 가지 종류의 문자 데이터 형식:

• non-유니코드(char,varchar,텍스트)
• 유니코드(nchar,이며,와원)

가 필요한 경우에 저장하는 문자 데이터를 여러 국가에서는,항상 사용하는 유니코드를 기반으로 합니다.

Answer 12

하지만 NVARCHAR 저장 유니 코드, Collation의 도움으로 고려해야합니다. VARCHAR 현지 언어의 데이터를 저장하십시오.

다음 시나리오를 상상해보십시오.

당신의 DB의 협업은 페르시아이며 당신은 VARCHAR(10) 데이터 형식. 문제가 없으며 DBMS는 3 바이트 만 사용하여 저장합니다.

그러나 데이터를 다른 데이터베이스로 전송하고 올바른 결과를 보려면 대상 데이터베이스 가이 예에서 페르시아인 대상과 동일한 충돌을 가져야합니다.

대상 콜렉션이 다르면 대상 데이터베이스에 일부 물음표 (?)가 표시됩니다.

마지막으로, 현지 언어를 사용하기 위해 거대한 데이터베이스를 사용하고 있다면 너무 많은 공간을 사용하는 대신 위치를 사용하는 것이 좋습니다.

나는 디자인이 다를 수 있다고 믿는다. 그것은 당신이 일하는 환경에 따라 다릅니다.

Answer 13

나는 여기서 말해야한다 (아마 나는 아마도 슬레이트에 나 자신을 열게 될 것임을 알고있다!) NVARCHAR 실제로입니다 더 유용합니다 (주목하십시오 더 거기!) VARCHAR 모든 종속 시스템과 데이터베이스 자체의 모든 콜라이트가 동일 할 때 ...? 그렇지 않다면, 콜라이트 변환은 어쨌든 발생해야합니다. VARCHAR 마찬가지로 실행 가능합니다 NVARCHAR.

이에 추가하기 위해 SQL Server (2012 년 이전) 페이지 크기는 약입니다. 8K. 따라서 검색 가능한 데이터를 보관할 수없는 경우 TEXT 또는 NTEXT 그때 필드 VARCHAR 전체 8K의 공간을 제공합니다 NVARCHAR 4K 만 제공합니다 (바이트의 두 배, 공간의 두 배).

요약하면, 어느 쪽의 사용이 다음에 의존한다고 가정합니다.

• 프로젝트 또는 컨텍스트
• 하부 구조
• 데이터베이스 시스템

Answer 14

따르다 SQL Server Varchar와 Nvarchar 데이터 유형의 차이. 여기에서 당신은 매우 설명적인 방식으로 볼 수 있습니다.

GeneralNvarchar에서는 데이터를 유니 코드로 저장하므로 데이터 열에 다국어 데이터 (둘 이상의 언어)를 저장하려면 n 변형이 필요합니다.

Answer 15

나는 답을 살펴 보았고 많은 사람들이 사용하는 것을 추천하는 것 같습니다. nvarchar ~ 위에 varchar, 공간은 더 이상 문제가되지 않기 때문에 추가 저장 공간이 거의없는 유니 코드를 활성화시키는 데 아무런 해가 없습니다. 글쎄, 이것은 열에 인덱스를 적용하고 싶을 때 항상 사실이 아닙니다. SQL Server의 한계는 인덱스 할 수있는 필드 크기에 900 바이트가 있습니다. 그래서 당신이 있다면 varchar(900) 여전히 색인을 표시 할 수는 있지만 그렇지 않습니다 varchar(901). 와 함께 nvarchar, 문자 수는 절반으로 줄어들므로 nvarchar(450). 따라서 자신이 필요하지 않으면 필요하지 않습니다 nvarchar, 나는 그것을 사용하지 않는 것이 좋습니다.

일반적으로 데이터베이스에서는 항상 확장 할 수 있기 때문에 필요한 크기를 고수하는 것이 좋습니다. 예를 들어, 직장의 동료는 한 번 사용하는 데 해가 없다고 생각했습니다. nvarchar(max) 저장에 전혀 문제가 없으므로 열의 경우. 나중에이 열에 인덱스를 적용하려고 할 때 SQL Server는이를 거부했습니다. 그러나 만약 그가 심지어 시작했다면 varchar(5), 우리는이 문제를 해결하기 위해 현장 마이그레이션 계획을 수행 해야하는 그러한 문제없이 나중에 나중에 필요한 것으로 간단히 확장 할 수있었습니다.

Answer 16

사이의 주요 차이점 Varchar(n) 그리고 nvarchar(n) 이다:

Varchar(가변 길이, 비 unicode 문자 데이터) 크기는 최대 8000입니다. 1. 가변 길이 데이터 유형입니다.

2. 비공개 문자를 저장하는 데 사용됩니다

3. 각 캐릭터에 대해 1 바이트의 공간을 차지합니다

Nvarchar: 가변 길이 유니 코드 문자 데이터.

1. 가변 길이 데이터 유형입니다

2. 유니 코드 문자를 저장하는 데 사용됩니다.

3. 데이터는 유니 코드 인코딩에 저장됩니다. 모든 언어는 지원됩니다. (예 : 아랍어, 독일어, 힌디어 등의 언어 등)

Answer 17

~ 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 varchar가 있습니다.

수백 개의 열이있는 테이블에 대한 특별한 요구 사항이 있습니다. 그 자체로는 드문 일입니까?

SQL*Server 2012의 8060 바이트 테이블 레코드 크기 한계에 가까워지는 것을 피하기 위해 Varchar를 선택합니다.

나에게 Nvarchar의 사용은이 8060 바이트 한도를 넘어냅니다.

또한 관련 코드 테이블의 데이터 유형을 기본 중앙 테이블의 데이터 유형과 일치시켜야한다고 생각합니다.

나는이 작업 장소 인 남호주 정부에서 Varchar 칼럼을 사용하는 것을 보았습니다. 테이블), 아마도 예상 데이터 행 볼륨 이이 결정의 일부가 될 것입니다.

Answer 18

nvarchar 비교하여 사용하기에 안전합니다 varchar 코드 오류를 무료로 만들기 위해 (유형 불일치) nvarchar 유니 코드 문자도 허용합니다. 우리가 사용할 때 where SQL Server 쿼리의 조건 및 사용중인 경우 = 연산자, 때때로 오류가 발생합니다. 이것에 대한 가능한 이유는 우리의 매핑 열이 다를 것입니다. varchar. 우리가 그것을 정의했다면 nvarchar 이 문제는 내 일이 일어나지 않습니다. 아직도 우리는 고집합니다 varchar 그리고 우리가 더 잘 사용하는이 문제를 피하십시오 LIKE 핵심 단어보다는 =.