많은 다음과 같은 표준을 따르도록 보인다127보다 작지 않은 한 SQL 필드 길이는 항상 (2^n) -1입니까? 큰 필드</p> <p><strong>(2^N) -1</strong> : 데이터베이스 스키마의
varchar(511)
varchar(255)
varchar(127)
... 다음 (2^n)의에 대한 작은 것들
varchar(64)
varchar(32)
varchar(16)
varchar(8)
I (2^N)의 수는 -1을 사용하는 이유는 작은 필드까지의 추세를 계속 할 필요가없는 이유, 내가 이해하지 못하는 것은 이해합니다.
예.
varchar(63)
varchar(31)
varchar(15)
varchar(7)
이유가 있습니까? 아니면 수익이 너무 줄었습니까?
2^n 길이를 사용하면 디스크 또는 메모리의 블록을보다 잘 정렬 할 수 있다는 것을 기억합니다. 정렬 된 블록이 빠릅니다. 오늘 "블록"크기가 더 크고 메모리와 디스크가 정렬을 무시할만큼 빠르며, 은 매우 큰 블록 인 경우 실행되지 않습니다. ("매우 큰"의미는 오늘 ....)
요즘은 그렇게하는 것이 전통적입니다.
또 다른 이유는 내가 유명한 말입니다 : 바이너리와 다른 사람들은 단지 10 가지 유형 만 있습니다.
그리고 2^n -1은 메르 센 소수의 후보입니다. 너무 괴상하기 때문에 ...
"-1"트렌드가 더 작은/큰 필드에 다르게 사용되는 것을 보았습니다. 그러나 나는 그 모든게 개발자/dba OCD 이상이라고 생각하지 않습니다. 항상 "예쁜"보다는 비즈니스 규칙에 따라 필드 길이를 결정할 때 항상 "둥근"번호를 원합니다.
사실 저는 그와 같은 "추세"에 대해 처음 들어 봤습니다. 내 varchar 필드는 항상 내가 필요로하는만큼 길다.
특별한 이유가 없습니다. 개발자의 선호도.
왜 내가 2^N 또는 2^N-1 번 필드에서 필드의 크기를 조정하는지 상상할 수 없습니다. SQL Server의 관점에서 보았을 때 SQL이 특정 이유보다 페이지 수준에서 해당 데이터를 저장하는 방법에 대한 오해와 같은 것처럼 들립니다.
나는 유형에 떨어져 잠재적 페이지 저장 (진흙/LOB) 행/페이지 + 비즈니스를 충족하는 2^N은 등
내가 생각하는 사용에 따라 공식보다 크기와 필요를 더 많은 관심을 지불 할 것 프로그래머가 공중에서 번호를 선택하는 것은 문제가되지 않습니다.
예를 들어 프로그래머가 아닌 사람은 100 또는 200자를 라운드 수로 선택하는 반면 프로그래머는 127이나 255를 라운드 수로 생각할 수 있습니다.
반환 값이 줄어들뿐만 아니라 임의의 제한으로 문자열 유형을 설정하면 문제를 해결하는 것보다 문제를 일으킬 확률이 높아집니다.
비즈니스 제약 조건 인 경우 길이에 TEXT 유형 (또는 이와 유사) 및 CHECK 제한 조건을 사용하고 적용하려는 비즈니스 제약 조건에 따라 번호를 선택하십시오.
DBMS는 어쨌든 varchar (x)와 똑같이 TEXT 유형의 저장소를 구현합니다. 그렇지 않으면 varchar에 이점이 있는지 여부를 고려하여 특정 시스템의 내부 저장 전략을 조사해야합니다.
2^n-1 문제 : 많은 프로그래밍 언어는 문자열 값을 종료하기 위해 null 바이트를 사용합니다 (파스칼은 문자열의 첫 번째 바이트에 길이를 저장하지 않지만 파스칼은이를 필요로합니다). 문자열을 저장할 1 바이트 이상. 이렇게하면 하나를 덜 사용하는 이유가 될 수 있습니다. – WegDamit