varchar (max)를 사용하지 않는 이유는 무엇입니까?

varchar (max)를 사용하지 않는 이유는 무엇입니까?

---

나는 데이터베이스 디자인에 관해서는 약간 오래된 학교이므로 열에 올바른 데이터 크기를 사용하는 데 전적으로 노력하고 있습니다. 그러나 친구의 데이터베이스를 검토 할 때 그가 varchar(max)많이 사용 하는 것을 발견했습니다 . 이제 내 즉각적인 생각은 그것을 그에게 다시 던져서 바꾸라고 말하는 것이었다. 그러나 나는 그것에 대해 생각했고 그가 그것을 사용하지 않는 좋은 이유를 찾을 수 없었습니다 (그는 당신이 궁금하다면 db를 생성하기 위해 케이스 유형 도구를 사용했습니다).

나는 varchar(max)사용에 관한 주제를 연구 해 왔고 그가 그것을 사용하지 않을 이유를 정말로 찾을 수 없습니다.

그는 인덱스에 열을 사용하지 않으며 db에있는 응용 프로그램은 입력에 제한이 있으므로 필드에 대량 항목을 허용하지 않습니다.

그가 빛을 볼 수 있도록 도움을 주시면 감사하겠습니다. :).

---

이에 대한 내 대답은 VARCHAR (max) 대 TEXT의 이유에 대한 것만 큼 Max의 사용에 관한 것이 아닙니다.

내 책에서; 우선, 영어 텍스트 외에는 어떤 것도 인코딩하지 않고 사람들이 외국 위치의 이름을 참조하지 않을 것이라는 확신이 없다면 NVARCHAR 또는 NTEXT를 사용해야합니다.

둘째, 필드를 통해 수행 할 수있는 작업입니다.

TEXT는 VARCHAR에 비해 업데이트하기 어렵지만 전체 텍스트 인덱싱 및 많은 영리한 기능을 활용할 수 있습니다.

반면 VARCHAR (MAX)는 약간의 모호함이 있으며, 셀의 크기가 8000 자 미만이면 행 데이터로 처리됩니다. 더 크면 저장 목적으로 LOB로 처리됩니다. RBAR를 쿼리하지 않고는이를 알 수 없기 때문에 데이터와 데이터 읽기 비용을 확인해야하는 장소에 대한 최적화 전략이있을 수 있습니다.

그렇지 않으면 사용량이 비교적 평범하고 데이터 크기에 문제가 없을 것으로 예상되는 경우 (IE는 .Net을 사용하고 있으므로 문자열 / char * 개체의 크기에 대해 걱정할 필요가 없습니다) 그런 다음 VARCHAR (max)를 사용하는 것이 좋습니다.

---

여기에 varchar max를 사용하지 않는 이유에 대한 블로그 게시물이 있습니다.

편집하다

기본적인 차이점은 데이터가 저장되는 위치입니다. SQL 데이터 행의 최대 크기는 8000 바이트 (또는 8K)입니다. 그러면 2GB varchar (max)를 데이터 행에 저장할 수 없습니다. SQL Server는 "Out of row"를 저장합니다.

따라서 데이터가 디스크의 동일한 위치에 있지 않기 때문에 성능이 저하 될 수 있습니다. http://msdn.microsoft.com/en-us/library/ms189087.aspx

---

OLTP 환경에서 작업하는 경우 성능이 가장 중요합니다. 오버 헤드 및 튜닝 문제부터 인덱싱 제한 및 쿼리 병목 현상까지. varcahr (max) 또는 다른 LOB 유형을 사용하면 대부분의 설계 모범 사례에 위배 될 가능성이 큽니다. 따라서 다른 입력 메커니즘을 사용하여 처리 할 수없는 특정 비즈니스 요구 사항이없고 varchar (max) 만 그렇다면 왜 시스템과 애플리케이션에 LOB 데이터 유형 중 하나에 내재 된 오버 헤드 및 성능 문제가 발생합니까?

반면에 OLAP 환경이나 Star Schema DW 환경에서 작업하는 경우에는 자연적으로 자세한 설명이 필요한 설명자 필드가있는 차원 테이블이있는 경우 varchar (max)를 인덱스에 추가하지 않는 한, 유용 할 수 있습니다. 그래도 char (x) varchar (x) 사용하는 것이 좋습니다. 항상 작업을 완료하기 위해 반드시 필요한 리소스 만 사용하는 것이 가장 좋습니다.

---

많은 양의 데이터를 기대하지 않는 한 사용해서는 안되며 그 이유는 다음과 같습니다 (온라인 설명서에서 직접 제공).

LOB (Large Object) 데이터 형식이 ntext, text, varchar (max), nvarchar (max), varbinary (max), xml 또는 image 인 열은 인덱스의 키 열로 지정할 수 없습니다.

성능을 저하 시키려면 모든 것에 nvarchar를 사용하십시오.

---

Redgate는 이에 대한 훌륭한 기사를 썼습니다.
https://www.red-gate.com/simple-talk/sql/database-administration/whats-the-point-of-using-varcharn-anymore/

결론

• 적절한 경우 VARCHAR (MAX)보다 VARCHAR (n)을 사용하여 성능상의 이점이 아니라면 좋은 디자인과 VARCHAR (MAX) 데이터가 압축되지 않기 때문입니다.
• 큰 문자열을 저장하는 것은 작은 문자열을 저장하는 것보다 오래 걸립니다.
• 행 내 VARCHAR (MAX) 값을 8,000 미만에서 8,000 이상으로 업데이트하는 것은 상대적으로 느리지 만 단일 트랜잭션의 차이는 측정 할 수 없습니다.
• 행 내 VARCHAR (MAX) 값을 8,000 이상에서 8,000 미만으로 업데이트하면 테이블이 행 외부에 데이터를 저장하도록 설정된 경우보다 빠릅니다.
• VARCHAR (MAX)에 대해 행 외부 옵션을 사용하면 문자열이 매우 길 때까지 쓰기 속도가 느려집니다.

---

SQL 서버가 성능, 메모리 및 스토리지 관점에서 대규모 (선언 된) varchar 필드를 처리하는 방법을 모르겠습니다.하지만 선언 된 더 작은 varchar 필드만큼 효율적으로 처리한다고 가정해도 무결성 제약 조건의 이점이 있습니다.

db에있는 애플리케이션 은 입력에 제한 이 있다고 가정 하지만 애플리케이션에 이와 관련하여 버그가있는 경우 데이터베이스가 오류를 올바르게보고 할 수 있습니다.

---

차이점은 다음과 같습니다 . 데이터 파일
VARCHAR(X)에 색인화 및 저장할 수 있습니다 MDF/NDF.
VARCHAR(MAX)대용량에 도달 할 수 있기 때문에 인덱싱 할 수 없으며 MDF/NDF데이터 파일이 아닌 별도의 파일로 저장됩니다 .

---

응용 프로그램이 짧은 문자열 만 데이터베이스에 전달    한다고 생각하는 것은 다소 구식 입니다.

   현대에, 당신은 가질 데이터베이스가 현재 응용 프로그램에 의해 주로 액세스 할 것이지만, 응용 프로그램의 향후 버전이있을 수 있음을 예상 할 수 (해당 버전의 노하우 개발자가 특정 길이 이하로 문자열을 유지하는 것인가?)

   당신은 반드시 그 웹 서비스, ETL 프로세스, SQL에 LYNC하고 데이터베이스에 액세스하는 데 사용됩니다 기존 및 / 또는하지 아직 기존 기술의 다른 수를 예상하고있다.

   일반적으로 말해서 varchar (4000)을 넘지 않으려 고합니다. 왜냐하면 그것은 결국 4 천자이기 때문 입니다. 이 값을 초과하면 저장하려는 데이터를 저장하기 위해 다른 데이터 유형을 찾습니다. Brent Ozar 는 이것에 대해 꽤 훌륭한 것들을 썼습니다 .

   즉, 프로젝트에서 작업 할 때 현재 요구 사항에 대한 현재 디자인의 접근 방식을 평가하는 것이 중요합니다 . 다양한 부분이 어떻게 작동하는지에 대한 아이디어를 가지고 다양한 접근 방식의 장단점을 이해하고 당면한 문제를 해결하십시오. 훌륭한 공리를 발휘하면 맹목적인 순응으로 이어질 수 있으며, 이는 당신을 멍청 하게 만들 수 있습니다 .

참고 URL : https://stackoverflow.com/questions/7141402/why-not-use-varcharmax