답변.

SQL에는 문자열 유형(예: VARCHAR, CHAR, TEXT), 숫자 유형(INT, DECIMAL, FLOAT), 날짜 및 시간(DATE, TIMESTAMP) 등 여러 기본 데이터 유형이 있습니다. 특정 데이터에 맞는 가장 작은 적합한 유형을 선택하는 것이 매우 중요하며, 이렇게 하면 공간을 절약하고 인덱싱을 최적화할 수 있습니다. 흔히 발생하는 오류는 길이가 과잉인 유형을 선택하는 것입니다(예: VARCHAR(255) 대신 VARCHAR(50)), 이는 불필요한 리소스 낭비로 이어질 수 있습니다.

또 다른 중요한 차이점은 숫자 유형인데, FLOAT는 근사값을 저장하고, DECIMAL은 정확한 값을 저장하며, 이는 금융 거래에 유용합니다. 서로 다른 인코딩의 문자열을 비교할 경우, COLLATE를 고려하지 않으면 예기치 않은 결과가 발생할 수 있습니다.

예시:

-- 데이터 유형 불일치 작업 예시
declare @price varchar(10) = '100.99';
select @price + 1;
-- 오류: 문자열과 숫자를 더할 수 없음
-- 명시적 데이터 유형 변환이 없으면 작동하지 않음

반전 질문.

질문: VARCHAR 유형 필드를 숫자와 비교하면 어떤 일이 발생합니까? 예를 들어: WHERE code = 123? 인덱스는 빠르게 작동할까요?

답변: SQL은 숫자를 문자열로 변환하려고 하고 문자열로 비교합니다. 그러나 이 필드에 숫자 인덱스가 생성된 경우, 문자열 비교에서는 사용되지 않으며 쿼리가 느려질 수 있습니다. 항상 엄격한 데이터 유형을 사용하고 필요한 경우 명시적 변환을 사용하는 것이 좋습니다.

예시:

SELECT * FROM products WHERE code = '123'; -- 인덱스 사용 가능
SELECT * FROM products WHERE code = 123;   -- 인덱스 사용 안 됨, 전체 스캔 가능성

---

사례

온라인 쇼핑몰에서 "가격" 필드를 VARCHAR로 저장하여 다양한 통화 형식을 지원했습니다. 몇 년 후, 상품을 가격별로 정렬할 필요가 생겼고, 정렬이 올바르게 작동하지 않았으며 인덱스화가 불가능했습니다. 복잡한 데이터 마이그레이션과 유형 변환이 필요했으며, 이는 몇 주가 걸렸습니다.

사례

한 은행에서 개발자가 수량 저장을 위해 FLOAT 유형을 사용했습니다. 보고서를 작성하는 동안 반올림으로 인해 불일치가 발생했으며, 1년 후 이는 상여금 배분에 큰 오류로 이어졌습니다.

사례

스타트업의 로그에서 날짜와 시간이 텍스트(VARCHAR)로 기록되었습니다. 간격을 계산할 필요가 생겼을 때, 시간이 모든 곳에서 서로 다른 형식으로 되어 있어 계산에 힘든 정규화 파싱이 필요했고, 이는 성능에 부정적인 영향을 미쳤습니다.