유효 테이블 빌드

효과적인 테이블 디자인은 모든 데이터베이스의 기초를 형성합니다. 테이블은 데이터를 구조화하고 쿼리가 정보에 액세스하고 수정하는 효율성을 결정합니다.

테이블 디자인 및 만들기

테이블은 엔터티와 해당 특성을 나타내는 행과 열로 데이터를 구성하는 관계형 데이터베이스의 기본 구성 요소입니다. 관계형 시스템에서 테이블은 트랜잭션 데이터를 저장하기 위한 구조를 정의하고 외세 키를 통해 관계를 적용하며 쿼리 및 보고의 토대를 제공합니다.

다차원 분석의 경우 테이블은 분석 컨텍스트를 제공하는 측정 가능한 이벤트 및 차원 테이블을 저장하는 팩트 테이블 역할을 합니다. 테이블(데이터 형식, 열 크기 조정, 제약 조건 및 관계)을 만들 때 내리는 디자인 결정은 운영 및 분석 워크로드 모두에서 스토리지 효율성, 쿼리 성능, 데이터 무결성 및 확장성에 직접적인 영향을 줍니다.

적절한 데이터 형식 선택

데이터 형식은 데이터베이스에 영향을 주는 기본적인 결정 사항입니다. 잘못된 선택은 스토리지 낭비, 성능 저하, 데이터 손실 또는 애플리케이션 오류로 이어질 수 있습니다. 쉽게 리팩터링할 수 있는 애플리케이션 코드와 달리 프로덕션 데이터베이스에서 열 데이터 형식을 변경하려면 테이블 다시 작성이 필요한 경우가 많으며, 이는 대규모 테이블의 가동 중지 시간을 의미할 수 있습니다.

초기 스키마를 디자인할 때 적절한 데이터 형식을 선택합니다. 가장 쉬운 시기이기 때문에 올바른 데이터 형식을 선택합니다. 또한 다음과 같은 경우 데이터 형식을 신중하게 고려합니다.

• 정밀도가 중요한 데이터를 저장하고 있습니다.
• 스토리지 비용이 증가하는 대용량 테이블로 작업하는 경우
• 더 작은 형식으로 더 빠르게 수행하는 자주 쿼리되는 열을 정의하고 있습니다.

일반적인 데이터 형식 살펴보기

적절한 데이터 형식은 스토리지, 성능 및 작업에 영향을 줍니다.

데이터 형식의 미묘한 차이는 주의해야 합니다. 예를 들어 재무 데이터를 대신 FLOAT 사용하면 DECIMAL 모든 종속 값을 다시 계산하지 않고는 해결할 수 없는 반올림 오류가 발생할 수 있습니다. UNIQUEIDENTIFIER 기본 기본 키가 INT 인덱스 크기를 세 배로 증가시키고 모든 JOIN 작업 속도를 저하시킵니다. 이러한 결정의 대부분은 데이터베이스의 성능에 영향을 줍니다. 쿼리가 밀리초 또는 분 단위로 실행되는지 여부를 결정할 수 있습니다.

테이블 크기 요구 사항 예측

테이블 크기는 스토리지 비용만을 위한 것이 아닙니다. 데이터베이스 작업에 직접적인 영향을 줍니다. 테이블 크기는 백업 및 복원 시간, 인덱스 다시 작성 기간 및 쿼리 성능에 영향을 줍니다.

테이블 크기 조정을 계획하는 또 다른 시나리오는 클라우드 데이터베이스에 대한 스토리지 비용을 계산하거나, 제한된 디스크 공간을 설계하거나, 보관 전략을 계획하는 경우입니다. 이러한 시나리오는 모두 리소스 및 작업에 대한 정보에 입각한 결정을 내리기 위해 정확한 크기 예측이 필요합니다.

예를 들어 매일 1억 개의 트랜잭션을 저장하고 행당 50바이트를 추가로 저장하는 소매 회사는 하루에 5GB를 낭비하며, 이는 불필요한 스토리지의 연간 1.8TB이며 백업 시간과 비용의 비례적 증가입니다.

다음 예제에서는 테이블의 크기를 Employee 예측하는 방법을 보여줍니다.

-- Estimate row size for a table
-- Fixed-length columns: sum of column sizes
-- Variable-length: estimate average size
-- Example row calculation:
CREATE TABLE Employee (
    EmployeeID INT,              -- 4 bytes
    FirstName NVARCHAR(50),      -- ~2-100 bytes (avg 40)
    LastName NVARCHAR(50),       -- ~2-100 bytes (avg 40)
    HireDate DATE,               -- 3 bytes
    Salary DECIMAL(10,2)         -- 5 bytes
);  
-- Estimated row size: 4 + 40 + 40 + 3 + 5 = ~92 bytes
-- Plus row overhead (~7 bytes) = ~99 bytes per row
-- 1 million rows ≈ 94 MB

효과적인 열 설계

다음 예제에서는 이 단원에서 다루는 원칙을 적용하는 잘 디자인된 Product 테이블을 보여 줍니다.

CREATE TABLE Product (
    ProductID INT PRIMARY KEY IDENTITY(1,1),       -- Auto-incrementing surrogate key (4 bytes)
    ProductName NVARCHAR(100) NOT NULL,             -- Unicode support, appropriate length, enforced
    Category NVARCHAR(50) NOT NULL,                 -- Smaller than ProductName (categorization needs less space)
    Price DECIMAL(10,2) NOT NULL,                   -- Exact precision for financial data
    StockQuantity INT NOT NULL DEFAULT 0,           -- Integer sufficient for inventory, default prevents nulls
    LastRestocked DATETIME2 DEFAULT GETUTCDATE()    -- Modern date type with automatic timestamp
);

이 표에서는 다음과 같은 몇 가지 모범 사례를 보여 줍니다.

• 적절한 데이터 형식: 기본 키로는 BIGINT 또는 UNIQUEIDENTIFIER보다 작은 INT를 사용, FLOAT 대신 DECIMAL(10,2)를 사용하여 정확한 재무 계산 수행, 그리고 레거시 DATETIME보다 정밀도를 높이는 DATETIME2 사용.
• 적절한 크기의 열: 예상 데이터 길이를 기준으로 제품 이름에는 NVARCHAR(100), 카테고리에는 NVARCHAR(50)를 사용합니다.
• 제약 조건: NOT NULL 중요한 값 누락을 방지하여 데이터 품질 보장
• 기본값: (0) 및 StockQuantity (현재 UTC 시간)에 대한 LastRestocked 자동 값은 애플리케이션 코드 복잡성을 줄입니다.
• 효율적인 기본 키: IDENTITY 효율적으로 클러스터하고 최소 스토리지를 사용하는 순차 키를 생성합니다(GUID의 경우 4바이트 대 16바이트).

디자인 모범 사례

성능 및 유지 관리 가능성을 보장하기 위해 테이블을 디자인하고 구현할 때 다음 주요 원칙을 적용합니다.

• 적절한 데이터 형식 사용 - 데이터 형식이 작을수록 스토리지가 줄어들고 성능이 향상됩니다.
• 테이블 크기를 일찍 고려 - 스토리지 및 인덱싱을 계획하기 위해 행 크기 및 총 테이블 크기 예측
• 의미 있는 제약 조건 구현 - 데이터베이스 수준에서 데이터 품질 보장
• 성장 계획 - 향후 데이터 볼륨을 처리하도록 테이블 디자인
• 인덱스 전략적으로 - WHERE, JOIN, 및 ORDER BY 절에서 사용되는 열에 인덱스를 생성합니다.
• 분석용 columnstore 선택 - 분석 쿼리가 있는 큰 테이블에 columnstore 인덱스 사용
• 적절한 경우 정규화 - 쿼리 성능 요구 사항과 정규화의 균형 조정
• 행 및 페이지 압축을 모니터링하기 - 대용량 테이블의 압축을 활성화하여 저장 공간 절약

대부분의 데이터베이스 성능 문제는 개발 초기에 내려진 잘못된 디자인 결정에서 비롯됩니다. 대형 데이터 형식은 스토리지 및 느린 쿼리를 낭비합니다. 누락되거나 잘못된 인덱스 유형은 리소스 업그레이드를 해결할 수 없는 병목 상태를 만듭니다. 테이블을 만들거나 수정하기 전에 적절한 개체 디자인에 시간을 투자하여 이러한 문제를 방지합니다. 적절한 데이터 형식 선택, 테이블 크기 예측, 올바른 인덱스 형식 선택 등 디자인 중에 내리는 결정은 나중에 적용할 수 있는 최적화보다 장기 성능 및 비용에 훨씬 더 큰 영향을 줍니다.