도당탕탕

저번 글에서 인덱스 스캔에 관련하여 공부를 했었습니다. 이번에는 인덱스의 사용목적에 대해 공부해보겠습니다. 인덱스 구조 인덱스를 생성하면 어떤 과정을 거칠까요? 아마 다음과 같이 이루어질 것입니다. 데이터베이스 엔진은 생성된 인덱스를 별도의 저장공간을 만듭니다. 인덱스화 된 데이터들을 별도의 저장공간에 저장시킨다. 위에서 봤을 때 인덱스 테이블도 같이 만들기 때문에 비효율적으로 보이지만, 테이블의 모든 로우를 매번 검색하지 않고 빠르게 데이터를 찾아올 수 있기 때문에 인덱스는 매우 유용하다고 생각합니다. 인덱스와 조인 관계 일단 조인은 무엇이며 왜 사용하는 것일까요? 조인은 여러 테이블에서 레코드를 조합하여 하나의 로우로 표현한 것이다. 운영중인 많은 서비스들에서 하나의 테이블에 모든 데이터를 담지 않습..

이번 글에는 인덱스를 왜 사용하는지, 인덱스 스캔과 테이블 스캔, 인덱스 종류 등 인덱스에 대해 공부해 보도록 하겠습니다. 인덱스를 왜 사용할까? 인덱스를 왜 사용할까요? 데이터베이스를 공부해보셨던 사람들은 아마 이런 생각을 할겁니다. 인덱스를 사용하면 빠르게 데이터를 찾을 수 있기 때문에 인덱스를 사용하는거 아냐? 네! 맞습니다. 테이블 풀 스캔하는 것 보다 인덱스 스캔을 하면 데이터를 빠르게 찾을 수 있다는 사실은 누구나 알고 있습니다. 하지만 여기서 궁금한점! 어느 상황에서든 인덱스 스캔이 테이블 스캔보다 빠를까요? 인덱스 스캔 VS 테이블 스캔 우선 인덱스 스캔과 테이블 스캔에 대해 보죠. 인덱스 스캔과 테이블 스캔의 정의는 다음과 같습니다. 인덱스 탐색 쿼리를 만족하는 레코드를 추출 하기위해 인..

RDB에서 NULL은 데이터가 들어가지 않은 특별한 값입니다. 따라서 NULL은 동등이나 연산자로 비교가 불가능하고 IS NULL 키워드를 통해 널 값이 있는지 없는지만 확인 할 수 있습니다. 인덱스는 보통 WHERE 조건 절엥 자주 사용되는 컬럼, 분포도가 높은 컬럼을 선정합니다. 그리고 인덱스를 통해 쿼리의 성능을 향상 시킵니다. 따라서 개발자는 인덱스를 설정할 때 해당 컬럼이 NULL을 포함하는지 혹은 NULL값을 포함한 인덱스를 시스템이 어떻게 처리하는지 등 고려해야합니다. 인덱스의 특별한 기능 데이터베이스 시스템에서 인덱스를 걸때 NULL를 제외해주고 인덱스를 생성할 수 있는 기능을 제공합니다. 만약 이런 기능이 없으면 어떻게 될까요? NULL도 인덱스가 되버려 저장 공간이 심각하게 낭비 될 것..

이번 글은 공부하면서 이해가 안갔던 용어들을 정리해 보는 시간을 갖을려고 합니다. 데이터베이스 엔진 첫번째로 볼 용어는 데이터베이스 엔진(스토리지 엔진) 입니다. 데이터베이스 엔진은 위키에서 다음과 같이 말합니다. 데이터베이스 엔진은 DBMS가 데이터를 삽입, 추출, 삭제, 수정을 사용하는 기본 소프트웨어 컴포넌트이다. 즉 DB에서 데이터를 어떠한 방식으로 저장하고 접근할 것인지, 데이터 접근이 얼마나 빠른지, 얼마나 안정적인지, 트랜잭션 관리 등 시스템을 운영하는 핵심적인 요소라 볼 수 있습니다. 또한 종종 데이터베이스 서버 또는 데이터베이스 관리시스템(DBMS) 라 불리기도 합니다. 데이터베이스 엔진을 조작하기 위해서는 다음과 같은 방법이 있습니다. DBMS 고유의 사용자 인터페이스를 이용하는 방법 ..

정규화된 테이블은 비정규화된 테이블보다 컬럼의 개수가 적고 저장 공간도 많이 차지하지 않기 때문에 성능이 좋아집니다. 또한 단일 공간으로 이루어진 데이터이기 때문에 갱신과 삽입이 빠르게 수행되고 중복이 없어 DISTINCT나 GROUP BY 사용을 현저하게 줄여줍니다. 데이터 웨어하우스에서 역정규화? 하지만 데이터 웨어하우스에서는 왜 역정규화를 사용해야 할까요? 아니 그보다 데이터 웨어하우스는 무엇일까요? 위키에서는 이렇게 말합니다. 데이터 웨어하우스(data warehouse)란 사용자의 의사 결정에 도움을 주기 위하여, 기간 시스템의 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스를 말한다. 즉 쉽게 말하면 데이터들을 수집하고 분석하는 즉 일종의 다차원 분석을 제공해주는 ..

여기 흔히 떠도는 말로 대부분의 애플리케이션은 제 3정규화만 해도 충분하다.가 있습니다. 많은 실무자, 현업자들은 일단 최대한 정규화한 후 애플리케이션이 제대로 돌아갈 때까지 역정규화하라고 말을 합니다. 사실 이 말들은 맞습니다. 대부분의 데이터 모델에서 이미 제 3정규화를 거친 엔티티는 더 높은 수준의 정규화를 만족할 가능성이 크기 때문입니다. 실제로 현재 많은 데이터베이스에서 이미 5정규화 6정규화 까지 도달해 있는데도 사람들은 이를 제 3정규화라고 칭합니다. 그렇다면? 우리는 어떻게 해야 할까요? 드물기는 하지만 제 3정규화를 만족하는 것처럼 보이더라도 데이터 이상 현상을 일으키는 설계 실수를 찾아야 합니다. 특히 제 3정규화로 설계했지만, 한 테이블이 다른 테이블 두 개 이상과 관계를 맺는다면 더..

이론적으로는 관련 컬럼의 데이터 타입이 같으면 테이블 간에 어떤 관계든 맺을 수 있습니다. 하지만 뭔가 할 수 있다는 이유만으로 반드시 해야 하는 것은 아닙니다. 대표적으로 비슷한 컬럼을 가진 테이블들의 컬럼 분리입니다. 예를 들어보죠. Customer, Employee, Vendor 테이블 구조 | Customer | | Employee | | Vendor | --------------------- --------------------- --------------------- | customer_id | | employee_id | | vendor_id | | cust_first_name | | empl_first_name | | vend_first_name | | cust_last_name | | e..

좋은 데이터베이스 스키마를 설계하려면 연관된 테이블의 기본키 값을 가지고 있도록 테이블의 외래키를 정의하는 것이 좋습니다. 예를 들어 Orders 테이블은 Customers 테이블의 기본키를 가리키는 customer_id나 customer_sequence 컬럼을 정의해 주문 고객 정보를 식별할 수 있게 해야 합니다. 다음은 카페와 메뉴간의 관계도를 다이어그램으로 간단하게 보여주는 그림입니다. Menus - Cafes 관계 다이어그램 위 그림에서 노란색 키는 기본키, 파란색 키는 외래키를 나타내며 화살표 방향을 통해 부자 관계를 알 수 있습니다. ( 다이어그램 사진의 일부분이라 테이블이 몇 개 없습니다. 참고해주세요!) 관계를 설명하면 다음과 같습니다. 카페 : 카테고리 -> 1 : 다 카테고리 : 메뉴 ..