데이터베이스 디자인에서 과장된 필드 크기

11

테이블에 대한 일부 필드가 문자열이며 현재 필드 크기의 대부분은 문자 제한이 매우 높습니다. 예를 들어 거리 이름은 100 자입니다. 큰 필드 크기를 사용하면 페널티가 있습니까? 예를 들어이 필드의 제한을 30 자로 변경하면 성능이 향상되거나 크기가 효율적입니까? 축소 후보가 될 수있는 약 50 개의 필드가 있습니다.

제안 해 주셔서 감사합니다.

sql-server

char의 경우 공간은 항상 데이터베이스에서 사용되지만 varchar의 경우 패널티는 줄어들지 만 실제로 필요한 공간을 더 많이 확보해야 할 필요는 있지만 여전히 효율성이 떨어질 수 있습니다. varchar (max) 또는 varchar (1000)을 항상 사용하는 것처럼 매우 큰 경우가 아니라면 varchar 열에 대해 걱정하지 않아도됩니다.

— Cade Roux

한 페이지 (8k)의 크기는 성능에 영향을 줄 수 있으므로주의해야합니다. 이 게시물을 확인하십시오 : stackoverflow.com/questions/2518922/…

저렴한 하드 드라이브 비용으로 인해 요즘 스토리지 효율성에 대해 걱정하지 않아도됩니다. JNK가 말했듯이, 매우 큰 필드의 인덱싱에 영향을 미칩니다. 이는 확실히 가치가 있습니다. 공간을 너무 적게 할당했기 때문에 응용 프로그램을 변경하는 데 따른 어려움은 데이터베이스 테이블의 몇 바이트 추가 비용보다 훨씬 큽니다.

— Neville Kuyt

3

스토리지가 싸기 때문에 무시하는 것이 좋지 않다고 생각합니다. 디스크의 모든 바이트를 가져 와서 처리해야하며 거의 모든 SQL Server 설치에서 가장 느린 부분은 디스크 저장소입니다. 적은 바이트 = 빠른 쿼리.

— JNK

1

100MB로 인해 512MB 디스크 컨트롤러 캐시에 20 % 적은 데이터가 들어가면 이는 절대적으로 중요합니다 (경험의 소리).

— Eric J.

16

당신이 얘기 varchar하고 nvarchar아니었다면, 더 높은 필드 길이를 허용하는 것에 대한 처벌은 없습니다.

하지만 몇 가지주의 사항을 명심해야합니다.

가변 길이 필드 (필드 당)에 대해 행당 2 바이트 오버 헤드가 있습니다 . 필드가 매우 짧은 경우을 사용하는 것이 더 합리적 일 수 있습니다 CHAR. Varchar(2)예를 들어 실제로는 행당 2-4 바이트를 CHAR(2)사용 하지만 항상 2를 사용합니다.
매우 긴 필드는 인덱싱 할 수 없습니다. 인덱스 키 세트의 모든 필드의 최대 길이는 900 바이트입니다.
예상보다 많은 데이터를 허용하면 예기치 않은 결과가 발생합니다. 거리 이름으로 100자를 허용하면 어느 시점에서 다른 데이터를 인식하지 않고 해당 필드에 입력 할 수 있습니다 (예 : 전체 주소). 적절한 크기를 사용했다면 삽입시 오류가 발생할 수 있습니다.
매우 넓은 행을 허용하면 페이지 분할 및 조각화가 발생할 수 있습니다. 8k보다 긴 행이 있으면 여러 데이터 페이지로 분할해야합니다. 이 중 많은 부분이 실제로 성능을 저하시킬 수 있습니다. 일반적으로 좁을수록 더 효율적입니다.

— JNK
소스

1

varco (30) 주소는 Bolderwood Arboretum Ornamental Drive 또는 Northeast Kentucky Industrial Parkway에 대처할 수 없습니다 .

@Aleksi-매우 사실입니다. OP가 넓은 분야를 사용하여 시작하는 이유가 더 분명하다고 생각합니다.

— JNK

"어떤 시점에서 다른 데이터는 그 사실을 알지 못하면 해당 필드에 들어갈 수 있습니다"흥미로운 점입니다. 사용자가 현재 레코드에 적용 할 수없는 필드를 범용 주석 필드로 사용하는 많은 시스템을 보았습니다.

2

벌칙이있을 수 있습니다

— Martin Smith

2

"실제로 저장된 값보다 더 큰 필드 크기를 선언하면 페널티가 있습니까?"라는 말이 varchar로 선언 된 경우 대답은 '아니요'입니다. 내가 아는 모든 SQL DB 엔진은 실제로 데이터에 주어진 문자 수 (길이 값) 만 저장합니다. 따라서 필드를 varchar (100)로 정의하고 10 자만 저장하면 디스크에서 10 자 (길이의 경우 2 바이트 정도) 만 사용합니다. 확실치 않은 경우, 나는 일상적으로 varchar 필드를 엄청나게 크게 만듭니다.

"긴 문자 필드를 저장하면 페널티가 있습니까?"라는 대답이 그렇습니다. 오늘날 디스크 공간은 저렴하지만 여유 공간이 없기 때문에 아무 이유없이 낭비하지 않습니다. 더 중요한 것은 디스크에서 데이터를 읽는 데 시간이 걸리므로 데이터 필드가 길수록 프로그램 속도가 느려집니다. 필드가 인덱싱되면 모든 읽기가 키 값을이 큰 긴 필드와 비교해야하므로 검색 속도가 느려질 수 있습니다.

사용자에게 빅 데이터 입력 필드를 제공하면 조만간 빅 데이터 입력 필드가 사용됩니다.

내가 말했듯이, 나는 너무 작은 것이 아니라 너무 큰쪽에 잘못을 범했다. 디스크 공간은 실제 데이터를 사용 가능한 필드에 맞출 수 없기 때문에 사용자가 약어를 즉석에서 발명하지 않게 할 정도로 충분히 저렴합니다. 현재 작업중인 시스템에는 실제 제품 이름에 비해 너무 작은 제품 설명 필드가 있으므로 사용자는 약어를 사용해야합니다. 물론 모든 사용자는 다르게 약어를 사용하기 때문에 20 가지 방법으로 같은 것을 말할 수 있습니다.

— 어치
소스

2

실제로 테이블에 저장 될 것보다 더 큰 필드 크기를 선언 한 것에 대해 페널티가 없다고 주장하는 사람은 부정확합니다. 데이터의 실제 크기 (2 바이트 오버 헤드 포함)는 실제로 저장되는 크기이지만 실행 계획이 진행되는 한 추정치를 결정하는 데 사용되는 열 정의입니다. 따라서 10 문자 값을 저장하기 위해 varchar (1000)을 선언하면 12 문자의 디스크 공간 만 소비되지만 실행 계획 추정은 작업을 부여하는 메모리 양과 작업을 메모리에서만 수행 할 수 있는지 여부 또는 tempdb 드라이브 공간이 필요한지 여부 열을 varchar (1000)로 만들 수 있지만 엔진은 저장된 모든 값이 varchar (10)보다 실제로 작다는 것을 알지 못합니다.

— 짐
소스

0

필드 길이 확인은 '무료'로 제공되는 것으로, CHECK동일한 작업을 수행 하기 위해 제약 조건을 사용할 필요가 없습니다 . 예를 들어, 국제 표준 주소에 따라 동일한 데이터 요소를 35 자로 제한하는 다른 데이터베이스에 데이터를 업로드해야하는 경우 너무 큰 데이터 값을 원하지 않습니다.

— 언젠가
소스