왜 여전히 varchar 데이터 형식이 있습니까?

많은 데이터베이스에는 varchars로 정의 된 필드가 있습니다. 제가 미국에서 살고 일한 이후로 큰 문제가되지 않았습니다 (존재하는 유일한 언어는 "American"입니다. ahem )

약 5 년 동안 데이터베이스 작업을 한 결과, 결국 varchar 필드의 제한된 특성에 문제가 생겼으며 데이터를 nvarchar로 저장하도록 필드를 수정해야합니다. varchar 필드를 nvarchar로 변환하여 테이블을 다시 업데이트 한 후 방금 생각했습니다. 왜 우리는 여전히 이런 식으로합니까? 나는 10 년 전 학교에있을 때 교과서에서 배운 것을 대신하여 varchar 대신 nvarchar에 새로운 모든 텍스트 필드를 정의하기로 오랫동안 정신적으로 결정했습니다.

2011 년이며 작년에 새로운 SQL Server 릴리스가있었습니다. 왜 nvarchar을 사용할 수 있고 사용해야 할 때 varchar 데이터 유형을 계속 지원합니까?

nvarchar가 varchar보다 "두 배"라고 주장하는 경우가 많으므로 저장 공간 사용은 varcar를 유지하는 데있어 하나의 논쟁이 될 수 있습니다.

그러나 오늘날의 사용자는 스토리지 공간을 절약하려는 경우 데이터를 기본 UTF-16 대신 UTF-8로 저장하도록 nvarchar을 정의 할 수 있습니다. 이것은 기본적으로 바람직한 경우 8 비트 인코딩을 허용하는 동시에 DB에 삽입되는 드문 2-8 바이트 문자가 아무 것도 깨지지 않도록 보장합니다.

뭔가 빠졌습니까? 지난 15-20 년 동안 이것이 바뀌지 않은 좋은 이유가 있습니까?

1. varchar 작업은 일부 데이터 정렬 문제가있는 많은 서유럽 언어 (노르웨이어, 덴마크어, 독일어, 프랑스어, 네덜란드어 등)에 충분합니다.

2. SO varchar vs nvarchar 성능에 대해서는 nvarchar가 성능에 심각한 영향을 미칩니다.

3. 이것은 MDY 대 DMY 날짜를 처리하는 것과 비교하여 사소합니다.

표준 및 호환성에 대한 답변 외에도 성능을 염두에 두어야합니다. 디스크 공간은 저렴한 것으로 쉽게 받아 들여지지 만 DBA / 개발자는 종종 쿼리 성능이 때때로 테이블의 행 / 페이지 크기와 직접적으로 관련되어 있다는 사실을 무시합니다. (필요할 때) NVARCHAR보다는 오히려 사용하면 VARCHAR문자 필드의 행 크기가 효과적으로 두 배가됩니다. 예를 들어 5 개 또는 10 개의 50 길이 필드가 있다면 행당 추가로 500 바이트를 추가 할 가능성이 있습니다. 넓은 테이블이 있으면 각 행을 여러 페이지로 밀어 넣고 성능에 부정적인 영향을 줄 수 있습니다.

많은 조직에 여전히 1 바이트 문자를 사용하는 대규모 응용 프로그램 기반, 인터페이스, 플랫폼 및 도구가 설치되어 있습니다. 데이터베이스는 거의 고립되어 있지 않으며 IT 에코 시스템의 일부입니다. 단일 바이트 문자에 의존하는 수천 개의 구성 요소와 수백만 줄의 코드가있는 경우 유니 코드로 전환하는 데 필요한 시간과 비용을 투자해야 할 합당한 이유가 필요합니다. 이 규모의 변경은 완료하는 데 몇 년이 걸릴 수 있습니다. 어떤 곳에서는 유니 코드가 여전히 비교적 새롭거나 거의 지원되지 않거나 완전히 지원되지 않습니다.

VARCHAR 및 NVARCHAR은 모두 ISO 표준 SQL의 일부입니다. SQL Server에서 VARCHAR 지원을 제거하거나 사용하지 않으면 호환성과 이식성이 한 단계 뒤떨어집니다.

또는 오늘날 사용자는 스토리지 공간을 절약하려는 경우 기본 UTF-16 대신 UTF-8로 데이터를 저장하도록 nvarchar을 정의 할 수 있습니다.

이것이 바로 대부분의 오픈 소스 데이터베이스가하는 일입니다 VARCHAR.

• MySQL은 제공 utf8및 ucs2"데이터 정렬".
• SQLite 는 UTF-8 (기본값)과 UTF-16 중에서 선택할 수 있습니다.
• PostgreSQL 은 UTF-8을 지원하지만 UTF-16은 지원하지 않습니다.

별도의 두 문자열 유형이 필요하지 않습니다.

마이크로 소프트는 8 비트 문자열이 레거시 인코딩 용이고 유니 코드 = UTF-16이라는 관점에서 이상합니다. 이는 아마도 Windows API 자체를 처리 하는 방식 char과 관련 wchar_t이 있습니다.

우리 중 일부는 유니 코드 기능이 필요하지 않은 최신 하드웨어보다 더 가볍고 작은 응용 프로그램을 구축하기 때문입니다. 나중에 변경해야 할 수도 있지만 지금은 필요하지 않습니다. 나는 내 문자열이 NVARCHAR 아래에 있어야 할 공간의 1/2을 차지하는 것을 좋아합니다.