기본 미션 :
p. 80
의shop_db
의 회원 테이블(member)
에서 아이유 회원에 대한 정보만 추출한 후 결과 화면 인증하기선택 미션 : 데이터베이스 개체 3가지 설명하기
8기, 9기에 이은 세 번째 혼공학습단이 시작되었습니다.
고등학교에 입학하면서부터 백엔드 개발자라는 직업에 흥미가 있었는데, 그것이 무색할 만큼 프로젝트에서 db를 다룬 경험이 현저히 적더군요.
프로젝트를 진행하며 db는 필수적인 요소이며, db를 잘 다루는 사람들을 보며 나도 저렇게 되고 싶다는 생각이 많이 들었습니다.
하지만 고등학교 1학년, 2학년에도 db와 관련된 과목이 없기도 했고 학기중에는 많이 바빴던 탓에 공부할 기회를 번번히 놓치다가 이제야 공부를 해보려고 혼공S를 신청하게 되었습니다.
이번 혼공단을 계기로 db를 배우고 다양한 프로젝트에 녹여 활용할 수 있는 역량을 가진 사람이 되고 싶습니다.
그럼 이번 혼공단10기에서도 최선을 다해볼게요!
p. 80
의 shop_db
의 회원 테이블(member)
에서 아이유 회원에 대한 정보만 추출한 후 결과 화면 인증하기데이터베이스 개체에는 인덱스, 뷰, 스토이드 프로시저가 각각 존재합니다.
쉽게 말하면 데이터베이스의 구성 요소에 인덱스, 뷰, 스토이드 프로시저가 존재한다는 뜻입니다.
그럼 데이터베이스 개체에 대해 조금 더 자세히 알아보도록 할까요?
데이터가 많아질수록 결과가 나오는 시간이 많이 소요되는데, 인덱스는 결과가 나오는 시간을 대폭 줄여줍니다.
인덱스는 특정 단어를 찾고자할 때 사용하는 찾아보기와 비슷한 개념입니다.
처음부터 특정 단어를 찾기에는 비효율적이므로 찾아보기를 통해 먼저 해당 단어를 찾고 바로 옆에 적혀있는 페이지로 이동하는 효율적인 방법을 사용하는 것이죠.
글로 읽으면 감이 잘 안 잡힐 것입니다.
바로 실습으로 들어가봅시다.
회원 테이블에는 아직 인덱스가 없는 상태입니다.
그 말인 즉슨 아이유라는 사람의 row를 찾을 때는 맨 처음의 row부터 전체 페이지를 찾아보게 될 것입니다.
당연히 효율이 떨어지겠죠.
결과는 당연히 아이유를 잘 찾았을 겁니다.
하지만 우리는 결과가 중요한 게 아니라 과정 속의 실행시간을 단축시키는 것이 중요합니다.
Execution Plan탭을 클릭하면 아이유를 찾은 방법을 볼 수 있습니다.
Full Table Scan이 나오는데, 이것은 바로 아이유를 찾을 때, 1페이지부터 전체 페이지를 다 둘러보며 찾았다는 말입니다.
굉장히 비효율적이죠.
CREATE INDEX idx_member_name ON member(member_name);
위의 SQL을 실행하면 idx_member_name
이라는 인덱스가 member
테이블의 member_name
열에 지정됩니다.
특별히 눈에 보이지는 않지만 Output
의 12번째 줄을 보면 인덱스가 정상적으로 만들어진 것이 보일 겁니다.
이제는 member테이블의 member_name에 인덱스가 지정이 되었습니다.
다시 이전의 커리문을 작성한 뒤 실행해봅시다.
결과는 이전과 똑같이 나오지만 Execution Plan을 클릭해보면 무언가 달라진 것을 확인할 수 있습니다.
Non-Unique Key Lookup이라는 것을 확인할 수 있는데, 간단히 말해서 Key Lookup은 인덱스를 통해 결과를 찾았다고 하는 겁니다.
실행시간도 0.65에서 0.35로 절반이 줄어들었군요!
좀 더 빨리 내용을 찾을 수 있게 된 것이지 찾는 내용에는 변함이 없습니다. 유의합시다.
테이블과 상당히 동일한 성격의 데이터베이스 개체인 뷰는 보안도 강화하고 SQL문도 간단하게 사용할 수 있습니다.
뷰를 한 마디로 정의하면 가상의 테이블이라고 정의할 수 있습니다.
실제 데이터를 가지고 있지 않은 진짜 테이블에 링크된 개념이라고 생각하면 됩니다.
뷰는 윈도우즈 운영 체제의 바로 가기 아이콘과 비슷한 개념이라고 생각하면 됩니다.
윈도우즈에서 바탕화면의 바로가기 아이콘을 더블클릭하면 해당 파일이 실행되지만 실제 실행되는 파일은 다른 폴더에 있습니다.
뷰도 이와 비슷한 개념으로 실체는 없으며 테이블과 연결되어 있는 것뿐입니다.
사용자가 뷰를 테이블처럼 생각해서 접근하면 알아서 테이블에 연결해줍니다.
그렇다면 뷰의 실체는 무엇일까요?
바로 SELECT입니다.
더 자세한 내용은 실습하며 알아보도록 합시다.
member테이블과 연결되는 member_view를 만들어주었습니다.
OutPut의 16번째 row를 보니 View가 정상적으로 만들어진 것을 확인할 수 있군요.
윈도우 브라우저의 바로가기처럼 member_view에 접근했더니 member테이블에 접근하게 되었습니다.
SQL 안에서도 일반 프로그래밍 언어처럼 코딩을 할 수 있습니다. 비록 일반 프로그래밍보다는 조금 불편하지만 프로그래밍 로직을 작성할 수 있어서 때론 유용하게 사용됩니다.
스토이드 프로시저는 MySQL에서 제공하는 프로그래밍 기능으로 여러 개의 SQL문을 하나로 묶어 편리하게 사용할 수도 있고, 연산식, 조건문, 반복문 등을 사용할 수 있습니다.
간단히 말해서 스토어드 프로시저를 통해 MySQL에서도 기본적인 형태의 일반 프로그래밍 로직을 코딩할 수 있다는 것입니다.
그럼 직접 실습을 통해 자세히 알아보도록 합시다.
이렇게 두 줄의 SQL문이 실행되었습니다.
그런데 이 두줄을 반복사용하는 곳이 많다면 매번 이 두줄을 치기 상당히 불편할 것이고, 문법을 잊어버리거나 오타가 날 수도 있습니다.
바로 이럴 때 스토어드 프로시저가 필요한 겁니다.
아래의 SQL을 입력하고 실행하면 두 SQL문을 myProc()라는 하나의 스토어드 프로시저를 묶어줄 수 있습니다.
DELIMITER //
CREATE PROCEDURE myProc()
BEGIN
SELECT * FROM member WHERE member_name = '나훈아';
SELECT * FROM product WHERE product_name = '삼각김밥';
END //
DELIMITER ;
CALL문을 사용하니 앞서 작성했던 두 줄의 SQL문을 실행할 수 있는 것을 확인할 수 있습니다.