테이블 의 수직 분할 과 수평 분할 에 대한 이해 
 ▶ 테이블 의 수직 분할 과 수평 분할 에 대한 이해 
 이병국 의 개발자 를 위한 DB 이야기 : 성능 ( 38 회 ) 
 예전 에 는 배우자 를 만나 결혼 을 하 면 그 생활 이 대체로 유지 되 었 다고 한다 . 하지만 요즘 은 시작 보다 결혼 생활 을 잘 유지 함 과 헤어 짐 이 더 중요 한 시대 가 된 것 같 다 . 누구 나 상대 를 만나 서 결혼 할 때 는 많 은 사람 의 축복 을 받 으면서 행복 한 가정 을 꿈꾼다 . 하지만 상대방 에 대한 좁힐 수 없 는 차이 를 발견 하 고 현실 의 벽 앞 에서 많 은 좌절 을 하 게 된다 . 헤어지 는 과정 에서 자녀 양육 에 대한 문제 와 재산 분할 에 대한 문제 등 으로 힘든 과정 을 겪 는 것 을 보 게 된다 . 그럼에도 이유 가 반드시 있 기 에 서로 갈라서 는 것 이 다 . 
 이번 연재 는 테이블 의 수직 분할 ( Vertical Partitioning ) 과 수평 분할 ( Horizontal Partitioning ) 에 관한 내용 이 다 . 합치 는 것 보다 는 나누 는 것 이 어렵 다는 말 이 있 듯이 테이블 의 분할 에 는 많 은 어려움 이 뒤따른다 . 기존 에 설계 된 테이블 구조 를 변경 해야 하 고 , 이미 개발 된 프로그램 에 많 은 변경 을 해 줘야 하 기 때문 이 다 . 그럼에도 성능 의 문제 를 해결 하 기 위해 테이블 을 나누 어야 하 는 경우 를 우리 는 간혹 경험 한다 . 이러 한 원인 은 DB 설계 시 정규 화 에 소홀 했 거나 용량 산정 을 잘못 계산 했 기 때문 이 다 . 
 이유 없 는 무덤 없 듯이 처음 설계 시 에 그렇게 잘못 된 설계 를 할 수 밖에 없 는 이유 가 반드시 있 게 마련 이 다 . 개발 일 정상 의 문제 혹은 기술 인력 지원 상 의 문제 등 으로 인하 여 정규 화 과정 을 무시 하 거나 소홀히 하 는 경우 가 종종 발생 한다 . 그럼에도 정규 화 는 반드시 되 어야 한다 . 일부 소규모 회사 나 1 인 기업 에서 는 DB 설계 없이 소프트웨어 를 개발 하 는 경우 도 있 다 . 이 는 말 도 안 되 는 일 이 다 . 설계 없이 짓 는 건 축물 이 얼마나 위험 한 일 인지 누구 나 다 알 듯이 DB 설계 없 는 프로그램 개발 은 아주 무모 한 행동 이 다 . 
 테이블 의 수직 분할 과 수 평분 할 
 테이블 의 수직 분할 은 컬럼 을 기준 으로 테이블 을 분리 하 는 것 을 의미 하 고 수평 분할 은 Row 를 기준 으로 테이블 을 분리 하 는 것 이 다 . 테이블 을 분리 하 는 이유 는 성능 개선 을 위한 것 이 다 . 기본 적 으로 테이블 의 Row 수 가 많 을수록 Index 에 대한 부하 가 따르 고 , 테이블 의 컬럼 수 가 많 을수록 I / O 에 대한 부하 가 걸린다 . 그렇 다고 모든 테이블 이 분리 를 통해 성능 개선 의 효과 를 보 는 것 은 아니 다 . 하지만 대용량 이 면서 성능 이슈 가 있 는 테이블 은 분리 를 통한 성능 개선 을 검토 해 볼 필요 가 있 다 . 
 테이블 의 수직 분할 과 수평 분할 에 대해 정확히 이해 하 는 개발자 는 그리 많 지 않 다 . 뭔지 모르 지만 특별 한 것 이 있 을 것 이 라고 생각 하 거나 나 와 는 무관 할 거 라고 생각 하 는 경향 이 있 다 . 하지만 [ 그림 1 ] 을 보 면 , 테이블 의 수직 분할 과 수평 분할 이 그리 특별 한 게 아님 을 알 수 있 다 . .... 
 2017 . 08 . 21 신용균 삭제 
 항상 좋 은 내용 감사 합니다 . 트랜잭션 성격 을 잘 알 아야 겠 네요 . DBA 입장 에서 는 개발자 가 먼저 이런 분 할 제안 을 하 는 경우 는 극히 드문 것 같 습니다 . ㅎ 
 2017 . 08 . 17 장 대호 삭제 
 개발자 가 말 하 는 법 : 자기 표현 의 ABC 
 빅 데이터 를 제대로 활용 하 기 위한 조건 : 데이터 확보 와 비즈니스 발굴