VARCHAR (255)이 너무 자주 사용되는 다른 이유가 있습니까?

158

여러 코스, 서적 및 작업에서 VARCHAR (255)로 정의 된 텍스트 필드를 "짧은"텍스트의 기본값으로 정의했습니다. 좋은 둥근 숫자 가 아닌 길이 255의 길이가 너무 자주 선택되는 이유가 있습니까? 과거에 좋은 이유가 있었을 때 (오늘 적용 여부에 관계없이) 어느 시점부터 개최되고 있습니까?

물론 문자열의 최대 길이를 알고 있다면 더 엄격한 제한이 더 이상적이라는 것을 알고 있습니다. 그러나 VARCHAR (255)를 사용하는 경우 아마도 최대 길이를 모른다는 것을 나타내는데 "짧은"문자열 일뿐입니다.

주 :이 문제 (찾을 VARCHAR (255) V의 TINYBLOB 브이 tinytext VARCHAR (말한다), n이 ) 요구 N +1의 저장 바이트 N <= 255, N 의 저장 +2 바이트 N > 255. 이것이 유일한 이유입니까? VARCHAR (256)에 비해 2 바이트 만 저장하므로 VARCHAR (253)을 선언하여 다른 2 바이트를 쉽게 저장할 수 있기 때문에 임의의 것으로 보입니다.

— 자다
소스

109

역사적으로, VARCHAR일부 DBMS에서 255자가 종종 최대 길이였으며 UTF-8을 사용하고 컬럼을 색인화하려는 경우 (인덱스 길이 제한으로 인해) 여전히 유효 최대 값이됩니다.

— 혼돈
소스

4

@CharlesBretana : 인용 한 나머지 문장을 읽으면 요청한 정확한 설명을 찾을 수 있습니다.

— 혼돈

2

@CharlesBretana : "가짜 UTF-8"은 MySQL의 "utf8"인코딩을 의미하며, 문자 당 3 바이트를 예약 (및 제한)합니다. 이것은 UTF-8의 좋은 버전이 아닙니다. MySQL에서 적절한 UTF-8을 원한다면 "utf8mb4"인코딩을 사용해야합니다. 그러나 사람들은 그 사실을 알지 못하고 "utf8"을 사용하고 다른 어떤 인코딩보다 UTF-8을 원할 가능성이 훨씬 높으므로 VARCHAR에서 최대 색인 가능한 길이는 255 자입니다. 그럼에도 불구하고 당신의 놀라운.

— 혼돈

3

@CharlesBretana : 이제 세 번 설명했지만 한 가지만 바뀌지 않았습니다. MySQL의 인덱스 길이 제한은 여전히 767 바이트이고, 3 바이트 UTF-8 문자를 인코딩하는 데 필요한 바이트 수는 여전히 3이며, floor (767/3)는 여전히 255입니다. 거지의 신념에 대해 혼란 스러울 무언가를 찾는 결정 .

— 혼돈

1

@CharlesBretana (이 파티 전체에 늦어서 죄송합니다) DB 전문가는 아니지만 혼돈의 말은 다음과 같습니다. 예 : 'Fake UTF-8'열의 길이는 255자를 초과 할 수 있지만 색인은 varchar의 처음 255 자에서만 작동하므로 완전히 색인화하려는 경우 효과적으로 최대 열을 만들 수 있습니다. 이제는 내가 그의 설명에 대해 이해 한 것뿐입니다. 잘못되었을 수도 있습니다. 나는 SQL 인덱스의 전문가가 아닙니다.

— Francis Lord

2

@CharlesBretana Chaos의 답변을 제대로 보면, 두 부분으로 분리되어 있음을 알 수있을 것입니다. 1. Varchar (255)의 역사적 이유는 매우 일반적입니다 (이전 DBMS에서는 최대였습니다), 2. 오늘날에도 앞서 언급 한 인덱스 제한으로 인해 일부에는 여전히 제한이 있습니다. 1 부와 2 부는 연결되어 있지 않습니다. 파트 1은 질문에 대한 실제 답변이고, 파트 2는 오늘날에도 여전히 제한적일 수있는 이유를 설명하기 때문에 여전히 질문과 관련이있는 부가 정보입니다. (계속->)

— Francis Lord

161

255는 8 비트 숫자로 계산할 수있는 최대 문자 수이므로 사용됩니다. 255보다 큰 문자를 계산하기 위해 다른 전체 바이트를 요구하지 않고 8 비트 카운트 사용을 최대화합니다.

이 방법을 사용하는 경우 VarChar는 바이트 수 + 1 만 사용하여 텍스트를 저장하므로 필드의 문자 수에 대한 하드 제한 (50과 같은)을 원하지 않는 한 텍스트를 255로 설정할 수도 있습니다.

— 로버트 하비
소스

90

나는 "다른 전체 바이트를 절실히 요구한다"라는 문구를 좋아한다. =)

— MusiGenesis

7

varchar가 UTF-8 인 DB의 경우에도 마찬가지입니까?

— antak

1

@antak : MySQL에서 InnoDB를 사용하면 모든 키 열이 767 바이트를 초과 할 수 없습니다. VARCHAR 열이 UTF8 인 경우 (각 문자가 최대 3 바이트를 차지할 수 있음) 열의 최대 허용 길이는 floor (767/3) = 255입니다. 정확히 "767"이 선택된 것으로 가정합니다.

— BlueRaja-대니 Pflughoeft

1

문자 집합이utf8 인 경우varchar(85) 교차 바이트 가 길이 바이트 를 1에서 2 바이트로 기울이는 한계 입니다. 가 있다면 utf8mb4, 그것은이다 varchar(63). 온라인 ALTER TABLE을 사용 하여 VARCHAR의 길이를 확장 할 수있는 최대 값이므로 중요 합니다. 결과적으로 varchar(2) charset utf8열이 있는 테이블을 만들고 주어진 거리를 얼마나 멀리 확장 할 수 있는지 확인 하여 해당 숫자를 도출 했습니다 ALGORITHM=INPLACE.

— antak

많은 "데이터베이스"Back In The Day가 자기 테이프에 저장되었다고 생각하면 훨씬 더 의미가 있습니다. 2의 배수로 크기가 지정된 "블록"으로 데이터를 읽는 것이 매우 일반적입니다. 이런 방식으로 데이터가 가장 효율적으로 저장되었습니다 (그리고 오래된 메인 프레임에서 실행했을 때의 효율성은 최적화 또는 중단 최적화와 같았습니다).

— TMN

23

아마도 SQL Server와 Sybase (둘 다 익숙한 이름)는 VARCHAR열의 문자 수에서 최대 255자를 사용했기 때문일 것 입니다. SQL Server의 경우 1996/1997 버전 7에서 변경되었지만 오래된 습관으로 인해 때때로 어려움이 따릅니다.

— 찰스 브레 타나
소스

8

특정 DB 및 버전을 인용하면 +1입니다. 그리고 "오래된 습관은 열심히 죽는다"는 아마도 모든 사람의 가장 진실한 대답 일 것입니다.

— Andrew M

17

: 나는 문자 그대로의 질문에 대답하지거야 아니 , 당신은 VARCHAR (255) (참가 종종 있으므로 사용을 참조 좋은 이유가없는 이유는 다른 답변에서 설명하고있는 바와 같이, 그냥 좋은 사람). 건축가가 VARCHAR (255) 대신 VARCHAR (300)을 선택했기 때문에 대폭 실패한 프로젝트의 많은 예를 찾을 수 없습니다. VARCHAR 대신 CHAR에 대해 이야기하더라도 이것은 거의 중요하지 않은 문제입니다.

— MusiGenesis
소스

255 중에서 1 바이트는 0.4 %입니다. 때때로 당신은 마지막 절반 정도를 걱정합니다. 때로는 그렇지 않습니다. 호스팅 및 성능 비용이 수십 달러에 달하면 신경 쓰지 않을 것입니다. 그들이 수백만에 달하면 아마 그럴 것입니다.

— Edward Brey

2

@EdwardBrey : Moore의 법칙이 여전히 유효하다면, 여기에 내 대답은 내가 쓴 것보다 16 배 더 유효합니다.

— MusiGenesis

컴퓨터가 우리를 도울 수있는 16 배 더 많은 방법을 발견하지 않은 이상. 속도는 여전히 기능입니다.

— Edward Brey

14

당신이 말할 때 2^8당신이 얻을 수 256있지만, 컴퓨터의 측면에서 숫자는 숫자에서 시작됩니다 0. 그럼 당신은255 IP를 얻거나 IP 자체의 인터넷 마스크에서 조사 할 수 있습니다.

255 8 비트 정수의 최대 값입니다. 11111111 = 255

도움이 되나요?

— exec.-
소스

1

정수를 사용하면 0에서 시작하여 255로 끝납니다. 그러나 문자열의 자리에서는 1 위부터 시작하므로 256 위에서 끝나는 것이 합리적이지 않습니다. 대신 1에서 시작했기 때문입니다. 0? string_length () 결과로 인해 varchar (256)에 대해서는 아직 완전히 동의하지 않지만 실제로는 확실하지 않습니다.

— HoldOffHunger

1

데이터베이스의 @HoldOffHunger 문자열은 길이가 0 자일 수 있으므로 길이가 8 비트로 저장 될 때 허용되는 길이 범위는 0과 255 사이입니다. 해당 문자열을 모두 말하려면 하나 이상의 문자가 있어야합니다. 8 비트 길이의 256 자 문자열을 지원할 수 있습니다.

— phoog

7

주 :이 문제 (찾을 VARCHAR (255) V의 TINYBLOB 브이 tinytext VARCHAR (말한다), n이 ) 요구 N +1의 저장 바이트 N <= 255, N 의 저장 +2 바이트 N > 255. 이것이 유일한 이유입니까? VARCHAR (256)에 비해 2 바이트 만 저장하므로 VARCHAR (253)을 선언하여 다른 2 바이트를 쉽게 저장할 수 있기 때문에 임의의 것으로 보입니다.

253을 선언하여 2 바이트를 절약 할 수 없습니다. varchar의 구현은 길이 카운터와 가변 길이의 종결되지 않은 배열 일 가능성이 높습니다. 즉, "hello"를 varchar (255)에 저장하면 6 바이트 (길이 1 바이트, 5 자 5 바이트)를 차지하게됩니다.

— 스테파노 보리 니
소스

3

이 문장이 모든 데이터베이스에 해당되는 것은 아닙니다. 많은 데이터베이스는 테이블에서 지정된 크기의 varchar 필드를 사용하므로 해당 필드가 행에 대해 변경 될 때 행을 이동할 필요가 없습니다.

— SingleNegationElimination

네, 맞아요. 구현에 따라 다릅니다. 사건을 확인하려면 공급 업체 매뉴얼을 확인해야합니다.

— Stefano Borini

2

허용 될 수 있지만 VARCHAR이 방법을 구현 하면 대신에 사용의 요점 을 모두 상실합니다 . VARCHARCHAR

— dan04

4

부호없는 1 바이트 숫자는 범위 [0-255]를 포함 할 수 있습니다. 255가 보이면 프로그래머가 기본적으로 생각하기 때문입니다.10 (농담을 얻을?) :)

실제로, 255는 MySQL에서 VARCHAR를 제공 할 수있는 가장 큰 크기였으며 인덱싱 및 기타 문제와 함께 TEXT를 통해 VARCHAR을 사용하는 이점이 있습니다.

— 가후 아
소스

4

MsOffice (버전 2000 또는 2002까지)와 같은 많은 응용 프로그램에서 셀당 최대 문자 수는 255 자입니다. 필드 당 255 자 이상을 처리 할 수있는 프로그램에서 해당 응용 프로그램으로 / 응용 프로그램에서 데이터를 이동하는 것은 악몽이었습니다. 현재, 그 한계는 점점 줄어들고 있습니다.

— 호아킨 몬테스
소스

2

0000 0000- > 이것은 8 비트 이진수입니다. 숫자는 비트를 나타냅니다.

당신은 그렇게 계산 :

0000 0000 → (0)

0000 0001 → (1)

0000 0010 → (2)

0000 0011 → (3)

각 비트는 켜기 또는 끄기의 두 값 중 하나 일 수 있습니다. 총 최고 수는 곱셈으로 나타낼 수 있습니다.

2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255

또는

2^8 - 1.

첫 번째 숫자가 0이므로 1을 뺍니다.

255는 상당히 많은 값을 가질 수 있습니다.

더 많은 비트를 사용할수록 최대 값은 기하 급수적으로 증가합니다. 따라서 많은 목적으로 비트를 더 추가하는 것은 과도합니다.

— 스코티 블레이드
소스

1

또 다른 이유는 RDO 및 ADO (COM 버전이 아닌 ADO.NET)와 같은 Windows의 매우 오래된 데이터 액세스 라이브러리에서 255자가 넘는 열에서 데이터를 가져 오기 위해 GetChunk라는 특수 메서드를 호출해야하기 때문입니다. varchar 열을 255로 제한하면이 추가 코드가 필요하지 않습니다.

— 부지 보이
소스