역사적으로 사람들이 데이터베이스 필드 크기에 256이 아닌 255를 사용하는 이유는 무엇입니까?

데이터베이스 필드의 크기가 255 자로 설정되어있는 경우가 종종 있습니다. 전통적 / 역사적 이유는 무엇입니까? 페이징 / 메모리 제한 및 성능과 관련이 있다고 가정하지만 255와 256 사이의 구별은 항상 혼란 스럽습니다.

varchar(255)

이것은 용량 또는 크기가 고려되는, 인덱서없는 , 그래서 255 256 선호 되는가? 바이트가 특정 목적 (터미네이터 또는 null 또는 기타)을 위해 예약되어 있습니까?

아마도 varchar (0)은 말도 안됩니까 (용량이 0입니까)? 어느 경우에 2 ^ 8의 공간은 반드시 256이어야합니까?

성능상의 이점을 제공하는 다른 규모가 있습니까? 예를 들어 varchar (512)가 varchar (511) 또는 varchar (510)보다 성능이 낮습니까?

이 값이 이전 및 새 모든 관계 데이터베이스에 대해 동일합니까?

면책 조항 -나는 DBA가 아닌 개발자이며 알려진 비즈니스 논리에 맞는 필드 크기 및 유형을 사용하지만 더 이상 관련이 없어도이 환경 설정 의 역사적인 이유 를 알고 싶습니다. 여전히 관련이 있다면 더).

편집하다:

답변에 감사드립니다. 크기를 저장하는 데 바이트가 사용된다는 의견이 있지만, 이것이 내 마음에 결정적으로 정착하지는 않습니다.

메타 데이터 (문자열 길이)가 동일한 연속 메모리 / 디스크에 저장된 경우에는 의미가 있습니다. 1 바이트의 메타 데이터와 255 바이트의 문자열 데이터는 서로 매우 잘 어울리 며 256 개의 연속 바이트 스토리지에 적합하며 깔끔하고 깔끔합니다.

그러나 ... 메타 데이터 (문자열 길이)가 실제 문자열 데이터와 별도로 저장되면 (아마도 마스터 테이블에), 1 바이트 정수만 저장하기 쉽기 때문에 문자열 데이터의 길이를 1 바이트로 제한해야합니다 메타 데이터가 조금 이상해 보입니다.

두 경우 모두 DB 구현에 의존하는 미묘한 것 같습니다. 255를 사용하는 관행은 널리 퍼져있는 것처럼 보이므로 누군가 어딘가에 좋은 사례를 주장했을 것입니다. 누구나 그 사건이 무엇인지 기억할 수 있습니까? 프로그래머는 이유없이 새로운 연습을 채택하지 않을 것이며, 이것은 한 번 새로운 것이었을 것입니다.

최대 길이가 255자인 DBMS는 단일 바이트를 사용하여 필드의 데이터 길이를 표시하도록 선택할 수 있습니다. 한계가 256 이상인 경우 2 바이트가 필요합니다.

길이가 0 인 값은 varchar데이터에 확실히 유효 합니다 (달리 제한되지 않는 한). 대부분의 시스템은 이러한 빈 문자열을 NULL과 구별하여 처리하지만 일부 시스템 (특히 Oracle)은 빈 문자열을 NULL과 동일하게 처리합니다. 빈 문자열이 NULL이 아닌 시스템의 경우 값을 NULL로 간주해야하는지 여부를 나타 내기 위해 행 어딘가에 추가 비트가 필요합니다.

아시다시피, 이것은 역사적 최적화이며 오늘날 대부분의 시스템과 관련이 없습니다.

255는 mySQL4 및 이전 버전 의 varchar 한계입니다.

또한 255 자 + Null 종료 자 = 256

또는 1 바이트 길이 디스크립터는 가능한 범위 0-255자를 제공합니다

255는 단일 바이트 부호없는 정수 (8 비트 바이트를 가정)에 저장할 수있는 가장 큰 숫자 값입니다. 따라서 어떤 목적으로 문자열 길이를 저장하는 응용 프로그램은 256보다 255를 선호합니다. "size"변수에 1 바이트를 할당하십시오.

MySQL 매뉴얼에서 :

데이터 타입 :
VARCHAR (M), VARBINARY (M)

스토리지 필요 :
열 값에 0 – 255 바이트가 필요한 경우 L + 1 바이트, 값에 255 바이트 이상이 필요한 경우 L + 2 바이트

이해하고 선택하십시오.

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

최대 길이는 255이며 데이터베이스 엔진은 1 바이트 만 사용하여 각 필드의 길이를 저장할 수 있습니다. 1 바이트의 공간을 사용하면 문자열 길이에 대해 2 ^ 8 = 256 개의 고유 한 값을 저장할 수 있습니다.

그러나 필드에 길이가 0 인 텍스트 문자열을 저장하도록 허용하면 길이에 0을 저장할 수 있어야합니다. 따라서 0에서 시작하여 256 개의 고유 한 길이 값을 허용 할 수 있습니다 (0-255).

종종 varchars는 pascal strings로 구현됩니다 : 바이트 # 0의 실제 길이를 유지합니다. 따라서 길이는 255에 바인딩되었습니다. 바이트 값은 0에서 255까지 다양합니다.

<<

비트 / 바이트 저장소의 기본 사항을 다시 수집하면 256 미만의 정수를 저장하려면 1 바이트가 필요하고 256과 65536 사이의 정수는 2 바이트가 필요합니다. 따라서 511 또는 512를 저장하거나 문제를 해결하려면 동일한 공간 (2 바이트)이 필요합니다. .... 따라서 위의 논의에서 언급 된이 주장은 varchar (512) 또는 varchar (511)에 대해 N / A라는 것이 분명합니다.

8 비트 부호없는 = 256 바이트

길이는 255 자 + 바이트 0

예전에는 모든 문자열에 NUL 터미네이터 또는 "backslash-zero"가 필요했습니다. 업데이트 된 데이터베이스에는 없습니다. "255 자 텍스트"이고 끝에 "\ 0"이 자동으로 추가되어 시스템은 문자열이 끝나는 위치를 알 수있었습니다. VARCHAR (256)이라고 말하면 결국 257이되고 한 문자의 다음 레지스터에있게됩니다. 낭비입니다. 이것이 모든 것이 VARCHAR (255) 및 VARCHAR (31) 인 이유입니다. 습관적으로 255가 멈췄지만 31 대는 32 대, 511 대는 512 대가되었습니다. 그 부분은 이상하다. VARCHAR (256)을 작성하기는 어렵습니다.

이것이 귀하의 질문에 대답 할 수 있다고 생각합니다. 이전 시스템에서 varchar의 최대 한계 인 것 같습니다. 나는 또 다른 stackoverflow 질문에서 벗어났습니다.

물론 가장 긴 우편 주소가 무엇인지 아는 것은 어렵습니다. 많은 사람들이 어떤 주소보다 확실히 긴 VARCHAR을 선택하는 이유입니다. 그리고 255는 새벽에 일부 데이터베이스에서 VARCHAR의 최대 길이 일 수 있기 때문에 관례 적으로 사용됩니다 (최근까지 PostgreSQL 포함).

모든 텍스트 기반 필드에 일반 varchar (255)를 사용하는 데 단점이 있습니까?

데이터는 이진 시스템의 메모리에 저장되며 0과 1은 이진수입니다. 1 바이트 (8 비트)에 들어갈 수있는 가장 큰 이진수는 11111111이며 10 진수 255로 변환됩니다.