특정 데이터 유형에 관계없이 응용 프로그램이 저장하도록 요청한 내용을 저장할 수 있어야합니다. 실제로 저장 될 최대 크기보다 작은 것을 지정할 수 없습니다.
또한 여러 가지 이유로 저장 될 실제 최대 크기보다 큰 열 길이를 지정할 필요도없고 원하지도 않습니다. 쿼리 메모리 할당, 잠재적으로 최대 행 크기를 채우고 열을 추가 할 공간을 남기지 않음 미래 등
사실 가변 길이 문자열 및 이진 열에는 고정 길이 데이터 유형 (문자열 / 이진 / 숫자 / 날짜 / 등)에 대한 스토리지 영향이 없습니다 (그러나 데이터 압축 또는 SPARSE열 정의 사용을 통해 이러한 영향 중 일부는 무시 될 수 있음) 선택권). 그러나 지적한 바와 같이 스토리지에 직접적인 영향이없는 경우에도 쿼리에 필요한 메모리를 과대 평가하는 성능에 여전히 영향을 미칩니다.
현명하게 행동하십시오. 필요한 것만 사용하십시오. 가까운 장래에 열 길이를 늘려야 할 가능성이 높으면 고려할 수 있지만 크기를 줄이는 것보다 열의 크기를 확장하는 것이 더 쉽다는 점을 명심하십시오. 예, 일부 작업이 수반되지만 그 작업은 "잠재적"일 뿐이므로 크기 초과에 따른 성능 영향은 "실제"이므로 실제로는 필요한 것이 아니라 실제로 필요한 것에 따라 열을 정의하는 것이 가장 좋습니다. 미래에 필요할지도 모른다고 생각합니다. 이야기되는 많은 변화는 결코 일어나지 않으며, 종종 필요한 변화는 예측할 수 없습니다. 당신이 알고있는 것과 함께 가십시오.
대신 가능한 경우 각 데이터 행의 실제 크기를 ~ 8000 바이트로 제한하는 것이 목표 일 수 있습니다.
나는 당신이 여기에서 무엇을 얻고 있는지 확실하지 않습니다. SQL Server는 물리적으로 8000 바이트 이상으로 제한합니다. LOB 유형 사용 - VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX), XML, 및 사용되지 않는 TEXT, NTEXT및 IMAGE유형 - 그 초기 페이지 크기 제한을 넘어 허용하지만, 그 때문에의 종류에 따라 포인터 (16 바이트 이상을 배치하고, 따라 만입니다 MAX유형을 사용할 때 행 외부에 저장되는 값의 크기 ). 데이터 페이지의 실제 물리적 한계는 변경되지 않았습니다.
목표는 불완전한 값이 의미를 잃거나 다운 스트림 문제를 유발할 수 있도록 최소한의 물리적 공간을 사용하여 앱 / 비즈니스가 깨거나 자르지 않고 저장해야하는 것을 저장하는 것입니다. 12,000 문자를 저장 해야하는 경우 필요한 VARCHAR(MAX)것이므로 사용하십시오 . 전화 번호 나 우편 번호를 저장하는 경우 사용하기에 부적합하고 사용하기 VARCHAR(100)에 부적합합니다 VARCHAR(MAX).
일부 고객 데이터는 약간 변동하기 때문에 일반적으로 해당 열에 대해 열을 필요한 것보다 약간 넓게 (예 : 15-20 % 더 크게) 만듭니다. 다른 특별한 고려 사항이 있는지 궁금합니다.
모든 시스템에 변동하는 데이터가 적어도 있습니까? 사람의 이름을 저장 한 모든 시스템이 적합합니까? 이름의 길이에는 상당히 큰 차이가 있습니다. 그리고 당신은 왕자와 같은 누군가가 가서 그들의 이름을 상징으로 바꾸게되었고 이제는 길이가 다른 완전히 다른 문제가 생겼습니다. 이것은 단지 상황입니다.
그러나, 악마의 옹호자를 잠시 연기하려면 : "필요한 것보다 15-20 % 더 큰"값이 실제 필요한 값 이 아닌 방법은 무엇 입니까? 새 열을 추가하는 것에 대한 토론이 있고 누군가가 50자를 제안한다고 말한 다음 다른 사람이 말합니다. "글쎄, 20 %가 60 명이므로 60 명을 가질 수 있기 때문에 60을 해봅시다." 고객이 60을 가질 수있는 것이 사실이라면 60은 실제 필요한 값이며 항상 50은 잘못된 것입니다.
물론 다음과 같은 이유로 데이터 소스에 대한 표시가 있으면 도움이 될 것입니다.
- "URL"을 1024로 만들고 누군가가 1060을 필요로하는 경우 1060이되어야합니다 (유사하게 URL을 만들고
VARCHAR도메인 이름에 허용되는 유니 코드 문자를 엉망으로 만든다는 불만이있는 경우 NVARCHAR). 그러나
- 누군가가 그 다음, 500 문자 제한 주석 필드 1000 개 문자를 추가하고자하는 경우는 여전히 필요한 500 명 (코멘트 덜 장황 ;-) 나에게 큰 도전이 될 수있을 것이 아니라,
ProductSKU더 나은 모두에 맞게 충분히 큰 수 고객의 SKU
초기 테이블 생성에 대해 이야기하고 있습니다. 고객은 우리에게 새 테이블을 보내기 시작할 것이라고 말하고 샘플 데이터 (또는 첫 번째 프로덕션 데이터 세트)를 보냅니다.이 데이터는 최종적으로 데이터를 보유하기 위해보고 테이블을 만듭니다. 우리는 샘플의 내용뿐만 아니라 향후 수입을 처리하기 위해 테이블을 만들고 싶습니다. 그러나 특정 행은 더 길어질 수 있으므로 채워집니다. 문제는 얼마이며 기술 지침이 있습니까?
당신은 여기서 많은 가정을하고 있습니다. 물론 일부 필드 가 커질 수 있습니다 . 그러나 다시는 그렇지 않을 수 있습니다. 또는 일부는 더 작아 질 수 있습니다. 일부는 비 유니 코드에서 유니 코드로 변경 될 수 있습니다 (한 번 세계가 점점 작아지고 있으며성에는 기본 ASCII / 미국 영어 문자 만 있다고 가정 할 수 없음). 또는 필드 전송을 중단 할 수 있습니다. 또는 미래에 하나 이상의 필드를 추가 할 수 있습니다. 이것과 다른 것들의 조합. 그렇다면 왜 VARCHAR열에 만 초점을 맞추고 있습니까? 현재 INT값을 보내고 1 년에서 2 년 내에 최대 값에 도달하여 BIGINT? 값이 0-5 인 "상태"필드가있는 경우 어떻게해야합니까?INT어느 쪽이 성장을 가능하게 TINYINT합니까?
안전하게 예측할 수있는 유일한 방법은 고객 데이터가 어떻게 변경 될지 예측하는 것이 올바른 것보다 더 자주 잘못 될 것이라는 것입니다. 그리고 올바른 것은 운 / 우연의 문제입니다 (행운이 아니라면 복권을 연주하십시오).
따라서 지침은 다음과 같습니다.
- 대답 할 수없는 질문에 답하는 데 시간과 에너지를 낭비하지 마십시오.
- 대신, 고객의 실제 데이터와 관련하여 가능한 많은 정보를 얻는 데 집중하고이를 활용하십시오 (예 : 데이터 중심 의사 결정 ;-).
이미 예제 데이터가 있습니다. 그러나 고객의 연락처 정보 (전화 및 / 또는 이메일)도 있다는 것을 잊지 마십시오. 연락하십시오! 데이터 사양을 요청하십시오 (시스템과 마찬가지로 현재 시스템에있는 데이터의 최대 길이는 35 일 수 있지만 시스템의 데이터 길이는으로 정의되어 VARCHAR(50)있으며 시스템은 최대 길이까지 수용 할 수 있습니다. 50). 또한, 단기 변경 계획이 있고 해당 데이터 유형 (유형 및 / 또는 크기)이 있는지 물어보십시오.