(n)varchar 열에 대해 어떤 크기를 선택해야 합니까?

https://stackoverflow.com/questions/1261441

12-09-2019
|

문제

안에 TDWTF에 대한 약간 열띤 토론 DB의 varchar 열 크기에 대한 질문이 생겼습니다.

예를 들어, 사람의 이름(성 없음)이 포함된 필드를 선택합니다.그리 길지 않을 것이라는 것을 쉽게 알 수 있습니다.대부분의 사람들은 10자 미만의 이름을 가지고 있으며 20자를 넘는 이름은 거의 없습니다.예를 들어 varchar(50)과 같은 열을 만들면 분명히 접하게 될 모든 이름이 포함됩니다.

그러나 대부분의 DBMS에서는 varchar(50)을 만들든 varchar(255)를 만들든 크기나 속도에 차이가 없습니다.

그렇다면 사람들은 왜 기둥을 가능한 한 작게 만들려고 할까요?어떤 경우에는 실제로 문자열 길이에 제한을 두기를 원할 수도 있지만 대부분은 그렇지 않습니다.그리고 드물게 이름이 극도로 긴 사람이 있는 경우에만 더 넓은 마진이 도움이 될 것입니다.

추가됨: 사람들은 "크기나 속도에는 차이가 없다"는 진술을 참조하고 싶어합니다.좋아요.여기 있습니다:

MSSQL의 경우: http://msdn.microsoft.com/en-us/library/ms176089.aspx

저장 크기는 입력된 데이터의 실제 길이 + 2바이트입니다.

MySQL의 경우: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

열 값에 0~255바이트가 필요한 경우 L + 1바이트, 값에 255바이트 이상이 필요한 경우 L + 2바이트

Oracle에 대한 문서를 찾을 수 없으며 다른 DBMS를 사용해 본 적이 없습니다.그러나 나는 그곳이 다르다고 믿을 이유가 없습니다.

해결책

나는 Oracle에 대해서만 말할 수 있습니다. varchar2 (50)와 Varchar2 (255)는 'Smith'값을 입력하면 정확히 같은 양의 공간을 차지하고 동일하게 수행합니다.

그러나 Varchar2 (4000)로 모든 텍스트 열을 선언하는 것이 일반적으로 좋은 생각이 아닌 이유는 열 길이가 효과적으로 다른 제약이기 때문입니다. 제약 조건은 비즈니스 규칙의 데이터베이스 구현이므로 데이터베이스 측면에서 정의되어야하는 것입니다.

원례로. 수용 할 수있는 값이 'y'및 'n'이되도록 열의 검사 제약 조건을 정의합니다. 이로 인해 응용 프로그램은 'Y'및 'N'또는 '1'및 '0'을 다루지 않아도됩니다. 검사 제약 조건은 데이터가 예상 표준을 준수하도록합니다. 그런 다음 응용 프로그램 코드는 처리해야 할 데이터의 특성에 대해 유효한 가정을 할 수 있습니다.

열 길이 정의는 같은 보트에 있습니다. 'ABC123zyx456'의 항목을 받아들이는 것을 원하지 않기 때문에 Varchar2 (10)가 된 것을 선언합니다 (어떤 이유로 든!)

호주에서는 '뉴 사우스 웨일즈'또는 '사우스 오스트레일리아'에 사람들이 입력하는 것을 원하지 않기 때문에 주 열을 Varchar2 (3)로 정의합니다. 열 정의는 거의 'NSW'및 'SA'로 입력해야합니다. 그런 의미에서 Varchar2 (3)은 실제로 체크인 ( 'NSW', 'SA', 'Vic'등) 제약 조건을 지정하는 것만 큼 많은 체크 제약 조건입니다.

요컨대, 적절한 열 길이는 비즈니스 규칙을 인코딩하는 방법입니다. 그것들은 또 다른 형태의 제약 조건입니다. 그들은 제약의 모든 장점을 가져오고 (그리고 동일한 단점을 많이 앓고 있습니다). 그리고 그들은 "적절한"제약 조건도 도움이되는 어느 정도의 '데이터 청결도'정도를 보장합니다.

나는 또한 변경하기가 더 쉽기 때문에 클라이언트 앱에서 이런 종류의 것들을 고수하는 것이 가장 좋다는 주장을 사지 않습니다. 앱을 사용하는 20,000 명이 있습니다. 20,000 개의 업데이트입니다. 데이터베이스가 하나 있습니다. 하나의 업데이트입니다. '클라이언트 앱을 쉽게 변경하기 쉽다'인수는 사실이라면 잠재적으로 데이터베이스가 클라이언트 코드에서 처리되는 모든 영리한 논리가있는 거대한 비트 버킷으로 취급된다는 것을 의미합니다. 그것은 큰 논의이지만, 모든 RDBMS가 데이터베이스 자체에서 제약을 정의 할 수 있기 때문에 그러한 기본 논리가 백엔드에 속해 있다는 것이 적어도 가치있는 경우가 있다는 것이 분명합니다.

다른 팁

쿼리 최적화기를 들었습니다 하다 참조를 찾을 수는 없지만 Varchar 길이를 고려하십시오.

Varchar 길이를 정의하면 의도를 전달하는 데 도움이됩니다. 금기판이 많을수록 데이터가 더 안정적입니다.

그렇다면 사람들은 왜 기둥을 가능한 한 작게 만들려고 할까요? 나는 가능한 한 작게 만드는 것이 아니라 적절하게 크기를 조정하는 것을 믿지 않습니다.(n)varchar를 더 크게 만드는 대신 작게 만드는 몇 가지 이유는 다음과 같습니다.

1) 더 큰 필드의 경우 데이터베이스를 사용하는 모든 클라이언트가 전체 크기를 처리할 수 있어야 합니다.예를 들어, 각 필드당 255자로 구성된 미국 주소를 보유하는 시스템을 살펴보겠습니다.(당신이 언급한 TDWTF와 유사하다고 생각합니다.)

이름
성
주소 라인 1
주소 2
도시
상태
우편 번호

이제 데이터 입력 화면에서는 필드당 255자를 허용하고 표시해야 합니다.어렵지는 않지만 더 큰 필드에서는 보기에 좋지 않을 것입니다. 송장을 인쇄할 때 큰 필드를 처리하려면 줄 바꿈 논리가 필요합니다.도구에 따라 다르지만 그렇게 어렵지는 않습니다.

그러나 각 필드 또는 해당 필드 중 하나에 대해 255자를 포함할 수 있는 봉투의 주소 형식을 지정하는 문제를 원하지 않습니다.필드가 너무 길어서 맞지 않으면 잘리나요?훌륭한 사람이 "집 번호 도로 번호..."의 주소 입력란 1을 가지고 있습니다.ㅋ ㅋ ㅋ ㅋ ㅋ ㅋ ...아파트 번호 111." 그리고 중요한 아파트 번호를 잘라내게 됩니다.포장할 건가요?얼마나 많이?봉투의 작은 상자에 넣을 수 없다면 어떻게 될까요?예외를 발생시키고 누군가 손으로 편지를 보내도록 하시겠습니까?

2) varchar(50)과 varchar(255)에 저장된 10자의 데이터는 크기나 속도에 영향을 미치지 않지만 255자를 허용하면 더 많은 공간을 차지할 수 있습니다.그리고 모든 필드가 너무 크면 SQL Server 2000에서 크기 제한에 도달할 수 있습니다.(2005년과 2008년에는 한 페이지보다 큰 행을 처리할 수 있는지 확인하지 않았습니다.) 그리고 Oracle을 사용하면 크기가 커지므로 누군가 실제로 사용 가능한 모든 문자를 사용하는 경우 행 체인이 발생할 수 있습니다.

3) 인덱스는 리프 페이지보다 더 엄격한 크기 제한을 갖습니다.varchar를 너무 크게 생성하면 인덱스, 특히 복합 인덱스가 제외될 수 있습니다.

반면에 내 주소에 대한 긴 줄 1이 있고 전체 주소를 입력하는 것을 허용하지 않는 웹 사이트 때문에 좌절감을 느꼈습니다.

한 가지 중요한 차이점은 임의로 큰 한계를 지정하는 것 사이의 것입니다 [예 : VARCHAR(2000)], 제한이 필요하지 않은 데이터 유형을 사용합니다 [예 : VARCHAR(MAX) 또는 TEXT].

PostgreSQL은 모든 고정 길이를 기초로합니다 VARCHAR무제한으로 s TEXT 입력하고 동적으로 결정합니다 값 당 페이지 외부 저장을 포함하여 값을 저장하는 방법. 이 경우 길이 지정자는 실제로 제약 일 뿐이며 실제로 사용이 권장되지 않습니다. (참조)

다른 DBMS는 일반적으로 편의 및/또는 성능 관련 비용으로 "무제한", 페이지 외, 저장 공간이 필요한 경우 사용자가 선택하도록 요구합니다.

사용에 이점이있는 경우 VARCHAR(<n>) ~ 위에 VARCHAR(MAX) 또는 TEXT, 값을 선택해야합니다. <n> 테이블을 디자인 할 때. 테이블 행의 최대 너비 또는 인덱스 항목이 있다고 가정하면 다음 제약 조건이 적용되어야합니다.

<n> 보다 작거나 같아야합니다 <max width>
만약에 <n> = <max width>, 테이블/인덱스는 단 1 열만을 가질 수 있습니다.
일반적으로 테이블/색인은 <x> (평균적으로) <n> = <max width> / <x>

그러므로 ~ 아니다 가치의 경우 <n> 제약으로 만 행동하며 <n> 디자인의 일부 여야합니다. (DBM에 단단한 제한이 없더라도 폭을 일정 한계 내에 유지 해야하는 성능의 이유가있을 수 있습니다.)

위의 규칙을 사용하여 a를 할당 할 수 있습니다 최고 가치 <n>, 테이블의 예상 아키텍처를 기준으로 (향후 변화의 영향을 고려). 그러나 정의하는 것이 더 합리적입니다 최저한의 가치 <n>, 예상을 기준으로 데이터 각 열에서. 아마도 가장 가까운 "라운드 숫자"로 확장 될 것입니다. 예를 들어 항상 사용할 것입니다. VARCHAR(10), VARCHAR(50), VARCHAR(200), 또는 VARCHAR(1000), 가장 잘 맞는 사람.

내 의견으로는 이에 대한 간단한 대답은 해당 열을 색인 키로 사용할 수 없다는 사실입니다. 인덱싱이 필요한 경우 기본적으로 FullText를 사용해야합니다 ... 이것은 Varchar (Max) 열을 사용하는 것과 관련이 있습니다. 어쨌든 '올바른 크기'열은 인덱싱을 적용하고 싶을 때마다 많은 의미가 있습니다. 가변 길이 열을 업데이트하는 것은 비용이 많이 드는 기동 일 수 있으며, 이들은 제자리에 수행되지 않으며 어느 정도의 조각화를 유발할 수 있습니다.

MS SQ-Server와 관련하여 모두.

질문으로 질문에 답할 것입니다. Varchar (50)와 Varchar (255) 사이에 DBMS에 차이가 없다면 DBMS가 왜 구별 할 수 있습니까? 왜 DBM이 단순히 "최대 xxx 문자에 Varchar를 사용하고 텍스트/클로브 등을 사용하십시오." 물론, 아마도 Microsoft/Oracle/IBM은 역사적 이유로 길이의 정의를 유지할 수 있지만, 여러 스토리지 백엔드가있는 MySQL과 같은 DBMS는 어떻습니까? 왜 정의 가능한 문자 열 길이를 구현합니까?

라벨을 인쇄하려는 경우 일반적으로 문자열이 35자를 넘지 않기를 원합니다.그렇기 때문에 라벨을 인쇄하는 데 사용될 라인을 수락하는 데 사용할 바르 차의 크기를 제어하려는 이유입니다.

데이터 길이를 255자 이상으로 허용하고 누군가 MS Access를 통해 데이터에 연결하는 경우 해당 데이터는 테이블 조인에 사용할 수 없습니다(메모 필드로 제공됨).데이터를 Excel로 내보내는 경우 필드당 255자로 제한됩니다.데이터 세트를 생성할 때 다른 프로그램과의 호환성을 고려해야 합니다.
데이터 품질 관리는 환경에 입력되는 데이터를 제어하는 것입니다.255자가 넘는 문자를 저장하려면 무엇을 저장해야 합니까?데이터가 255자를 초과해야 하는 경우가 있지만 그 사이는 멀고 적어야 하며 분석에 사용할 수 있는 분야에 대한 지원 보충 정보로 사용해야 합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow