VARCHAR 크기를 128/256/4096 바이트 오프셋으로 반올림해야하는 이유가 있습니까?

데이터베이스 스키마에서 VARCHAR 크기가 바이트 오프셋 128/256 또는 4096으로 반올림되는 경우가 종종 있습니다. 이전에도 해봤으며 그 뒤에있는 아이디어는 아마도 효율적인 것입니다.

그러나 오늘날에도 그렇게 할만한 정당한 이유가 있습니까? 요즘에는 VARCHAR 크기로 '50', '100'또는 '200'을 사용하는 경우가 많습니다. 더 자연스럽고 일반적으로 사용자에게 유효성 검사를 표시하기 때문입니다.

내가 생각할 수있는 유일한 합리적 설명은 : DBMS가 열의 값을 순차적으로 저장하고 크기가 2의 거듭 제곱으로 반올림되지 않으면 일부 요소가 하드의 두 페이지로 "분할"될 수 있습니다. 드라이브 (예 : n 페이지의 처음 10 바이트 및 n + 1 페이지의 다음 40 바이트). 하드 드라이브에서 1 개 대신 2 번 읽게 될 수 있습니다.

@Jan Hudec의 주장은 많은 프로그래머들이 "128"또는 "256"을 "좋은 둥근 숫자"로 생각하기 때문에 137, 19 또는 100과 같은 홀수보다 더 자연스러운 선택입니다.

일반적으로 이러한 열 길이에 대한 이유는 없습니다. varchar (128) 열에 비해 varchar (100) 열의 성능 향상은 없습니다.

그러나 제한 및 기타 공급 업체별 경고에 대한 자세한 설명을 위해 사용중인 데이터베이스 시스템을 다시 확인합니다.

예를 들어 다음은 SQL Server에 대한 데이터베이스 시스템 제한의 좋은 예입니다.

http://msdn.microsoft.com/en-us/library/ms186981.aspx

행의 총 길이는 개별 열 길이보다 중요합니다.

나는 그것이 DBMS인지 컴파일러인지 기억하지 못하지만 배열과 열 길이에 2의 거듭 제곱을 사용하는 법을 오랫동안 기억합니다. 구현이 비트 시프 팅을 사용할 수 있기 때문에 그것이 더 빠르다는 정당화가 있었다. 더 이상 사실이 아닌지는 공개 된 질문입니다. 아직 유효한지 아는 사람이 있습니까?

BTW 열 너비를 균일 한 숫자 b / c로 옮겼습니다. 문자 제한이 256 자라고 말하는 것은 이상합니다.

그리고 아주 오래된 데이터베이스는 256 자 너비 열로 제한했습니다.

전체 행의 크기가 2의 거듭 제곱 인 경우 실제로 스토리지 효율성을 볼 수 있기 때문에 실제로 중요하지 않습니다. 2의 거듭 제곱으로 고정하면 행 크기가 더 커질 수 있습니다. (데이터베이스에 따라) 대부분의 기본 데이터 유형이 2의 거듭 제곱 인 경향이 있기 때문에 2의 거듭 제곱으로 작동하지만 어렵고 빠른 규칙은 아닙니다.

큰 (4K 이상) 열을 사용하여 작업하는 경우 열을 개별적으로 저장하고 하나의 저장소 블록 (데이터베이스가 디스크상의 저장소에 사용하는 것)에 맞도록 크기를 조정할 수 있으므로 크기를 조정하는 것이 더 의미가있을 수 있습니다. 당신은 뭔가.

모든 DBMS 시스템에 익숙하지는 않지만 Oracle에서 가장 작은 "물리적"스토리지 단위는 "블록"이며 기본적으로 2KB입니다. 2의 거듭 제곱으로 열 크기를 조정하는 방법은 스토리지 블록에 맞게 열 크기를 조정하는 큰 방법의 일부입니다. 하나의 행에 블록 크기보다 1 바이트 더 필요한 열의 크기를 지정하려면 두 블록을 할당해야하고 행도 두 블록에 걸쳐 있으므로 각 행에 하나의 블록을 맞추는 것보다 읽기, 삽입 및 스캔에 더 많은 시간이 소요됩니다 (각 블록에 하나의 행만 있습니다). 그것은 적어도 역사적인 이유입니다. 오늘날 대부분의 사람들은이 관행을 하위 최적화라고 생각합니다.