시작!

사실 이번 미션에는 아는 내용이 나와서 구현 하는게 수월했습니다.
그런데 확장성이 좋은 구조를 생각하느라 처음에 시간이 많이 걸렸었습니다.
시작은 좋았던것같은데 중간에서 꼬여버린것 같습니다 ㅋㅋㅋㅋ

그래도 이제 완전히 제 페이스를 찾은것같습니다.
잠도 잘 자고 코딩도 잘 되고 학습도 잘 되고있습니다!!
여러모로 기분좋은 이틀이었습니다.

그리고 예전에 학습했던 내용을 한번 더 정리한걸 다시 정리하니 분량이 상당합니다..😨

1. 데이터베이스란?

💡 Database는 일정한 규칙 혹은 규약을 통해 구조화 되어 저장돼있는 데이터의 모음

해당 데이터베이스를 관리하는 통합 시스템을 DBMS(Database Managament System)이라 한다.

그리고 DBMS마다 정의된 쿼리 언어(query language)를 통해 삽입, 삭제, 수정, 조회를 수행할 수 있다.

그리고 데이터베이스는 실시간 접근과 공유가 가능하다.

• dbms, db 관계를 나타내면 이렇다.

1-1. 엔터티

💡 사람, 장소, 물건, 사건, 개념들 여러개의 속성을 지닌 명사를 의미한다.

• 위처럼 회원이라는 엔터티가 있다면 회원은 이름, 아이디, 주소, 전화번호의 속성을 가질것이다.
• 이보다 많은 속성이 존재할 수도 있곘지만 서비스의 요구사항과 무관한 속성이라면 사라지게 된다.

강한 엔터티와 약한 엔터티

엔터티는 강한 엔터티와 약한 엔터티로 나뉜다.

만약 A라는 엔터티는 혼자서는 존재 못하고 B의 존재 여부에 따라서 종속적이라면

A는 약한 엔터티, B는 강한 엔터티가 된다.

예를들어 사원이라는 엔터티가 있다면 사원은 아이디등을 사용해 고유하게 엔티티를 식별할 수 있기에 강한 엔터티 타입이다. 하지만 사원에 부양가족 엔터티가 있다면 부양가족은 사원 엔터티에 종속적이기에 부양가족 엔터티는 약한 엔터티타입이 된다.

1-2. 릴레이션(relation)

💡 데이터베이스에서 정보를 구분해 저장하는 기본단위다.
엔터티에 관한 데이터를 데이터베이스에서는 릴레이션 하나에 담아서 관리하게 된다.

위처럼 회원이라는 엔터티가 데이터베이스에서 관리될 때 릴레이션으로 변화된걸 알 수 있다.

릴레이션은 관계형 데이터베이스에서는 테이블 이라고 하며

NoSQL 데이터베이스에서는 컬렉션 이라고 한다.

테이블과 컬렉션

데이터베이스의 종류는 크게 관계형 데이터베이스와 NoSQL 데이터베이스로 나뉠수 있다.

대표적인 관계형 데이터 베이스인 MySQL과 대표적인 NoSQL 데이터베이스인 MongoDB를 예로 들자면

MySQL의 구조는 레코드 - 테이블 - 데이터베이스로 이뤄져있고

MongoDB의 데이터베이스 구조는 도큐먼트 - 컬렉션 - 데이터베이스로 이뤄져 있다.

1-3. 속성

💡 릴레이션에서 관리하는 구체적이며, 고유한 이름을 갖는 정보이다.

예를들어 차라는 엔터티의 속성을 뽑아보면 차 넘버, 바퀴 수, 차 색깔, 차종 등이 있을것이다.

이 중 서비스의 요구사항을 기반으로 관리해야 할 필요가 있는 속성들만 엔터티의 속성이 된다.

1-4. 도메인

💡 릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합이다.

예를들어 성별이라는 속성이 있다면 해당 속성은 {남, 여} 라는 집합이 된다.

즉, 성별 속성의 도메인은 {남, 여}다.

1-5. 필드와 레코드

위에서 설명한것을 기반으로 필드와 레코드로 구성된 테이블을 만들 수 있다.

회원이라는 엔터티는 member라는 테이블로 속성인 이름, 아이디, 주소, 전화번호를 가지고

name, ID, address, phoneNum의 필드를 가진다.

그리고 이 테이블의 쌓이는 행(row)의 단위를 레코드라고 한다. 또한, 레코드를 튜플이라 하기도 한다.

예제

책이라는 엔터티를 정의하고 이를 기반으로 MySQL에서 테이블을 만들때의 예시다.

1. 책의 속성은 제목, 가격, ISBN, 저자, 출판년도등이 있다.
2. 이 중 제목, 저자의 아이디, 출판년도, 장르, 생성 일시, 업데이트 일시만 있다고 가정하겠다.

이제 이 엔터티를 가지고 테이블을 만들려면 속성에 맞는 타입을 정의해야 한다.

• 책 아이디: id
• 제목: VARCHAR(255)
• 저자 아이디: INT
• 출판년도: VARCHAR(255)
• 장르: VARCHAR(255)
• 생성 일시: DATETIME
• 업데이트 일시: DATETIME

이를 테이블로 만들면 아래와 같다.

1-5-1. 필드타입

💡 필드는 타입을 갖는다.

예를들어 이름은 문자열이고, 전화번호는 숫자이다. 이러한 타입은 DBMS마다 다르며, 여기서는 MySQL을 기준으로 설명하도록 하고, 대표적인 타입인 숫자, 날짜, 문자 타입에 대해 설명하도록 한다.

숫자 타입

타입	용량(바이트)	최솟값(부호 있음)	최소값(부호 없음)	최댓값(부호 없음)	최댓값(부호 있음)
TINYINT	1	-128	0	127	244
SMALLINT	2	-32768	0	32767	65535
MEDIUMINT	3	-8388608	0	8388607	16777215
INT	4	-2147483648	0	2147483647	4294967295
BIGINT	8	-263	0	263-1	264-1

날짜 타입

타입	용량(바이트)	지원범위	특이사항
DATE	3	1000-01-01 ~
9999-12-13	시간부분이 없는 값에 사용된다.
DATETIME	8	1000-01-01 00:00:00 ~
9999-12-13 23:59:59	날짜 및 시간부분을 모두 포함하는 값에 사용
TIMESTAMP	4	1970-01-01 00:00:00 ~
2038-12-31 03:14:07	날짜 및 시간부분을 모두 포함하는 값에 사용

문자 타입

1. CHAR과 VARCHAR

CHAR과 VARCHAR은 그 안에 수를 입력해서 몇 자까지 입력할지 정한다.

예를들어 CHAR(30)은 최대 30글자까지 입력할 수 있다.

그리고 CHAR의경우 테이블을 생성할 때 선언한 길이로 고정되고 0~255의 길이를 가진다.

레코드를 저장할때는 무조건 선언한 길이 값으로 고정 돼서 저장된다.

VARCHAR의 경우 0 ~ 65,535 사이의 값으로 지정할 수 있고 레코드를 저장할 때 입력된 데이터에 따라 용량을 가변시켜 저장한다. 예를들어 VARCHAR(10000)으로 선언해도 10글자가 저장된다면 10바이트 + 길이 기록용 1바이트가 저장되게된다.

1. TEXT와 BLOB

두 타입 모두 큰 데이터를 저장할 때 쓰이는 타입이다.

TEXT는 큰 문자열 저장에 쓰며 주로 게시판의 본문을 저장할 때 쓴다.

BLOB은 이미지, 동영상 등 큰 데이터 저장에 쓴다. 보통은 아마존의 이미지 호스팅 서비스인 S3에 파일을 올리고 그 경로를 VARCHAR로 저장한다.

1. ENUM과 SET

두 타입은 문자열을 열거한 타입이다.

ENUM은 ENUM(’x-small’, ‘small’, ‘medium’, ‘large’, ‘x-large’) 형태로 쓰이며 이중 하나만 선택하는 단일 선택만 가능하고, ENUM리스트 에 없는 잘못된 값이 삽입되면 빈 문자열이 대신 삽입된다.

ENUM을 사용하면 위의 문자열이 0, 1 등으로 배핑돼 메모리를 적게쓰고, 최대 65,535개의 요소가 들어간다.

SET은 ENUM과 비스사지만 최대 64개의 요소만 집어넣을 수 있다.

만약 ENUM과 SET을 사용하면 공간적으로 이점을 볼 수 있지만 애플리케이션 수정에 따라 데이터베이스의 ENUM 혹은 SET에서 정의한 목록에서 수정해야 한다는 단점이 존재한다.

1.6 관계

💡 관계형 데이터베이스에서 관계란 두 엔터티 관의 관계를 말한다.

관계는 아래의 관계 화살표로 나타낸다.

1-6-1. 1:1 관계

유저당 이메일은 한개씩 있을것이다. 이 경우 1:1 관계가 된다.

1:1 관계는 테이블을 두 개의 테이블로 나눠 테이블 구조를 더 이

1-6.2: 1:N 관계

쇼핑몰에서는 한 유저당 여러개의 상품을 장바구니에 넣을 수 있을것이다.

이 경우 1:N 관계가 된다. 0개일 경우도 있으니 0개도 포함해서 화살표를 표현한다.

1.6.3: N:M 관계

학생과 강의의 관계를 정의한다면 학생도 여러개의 강의를 들을 수 있고, 강의도 여러명의 학생을 포함할 수 있다. 이런경우에 N:M 관계가 된다.

그런데 테이블이 두개가 아니라 세개인 모습을 볼수있는데

N:M 관계는 중간에 1:N, 1:M 관계를 갖는 테이블을 나눠서 설정한다.

1-7. 키

💡 테이블간의 관계를 조금 더 명확하게 하고 테이블 자체의 인덱스를 위해 설정된 장치이다.

키는 기본키, 외래키, 후보키, 슈퍼키, 대체키가 존재한다.

슈퍼키는 유일성을 가지며, 그 안에 포함된 후보키는 최소성을 가진다.

그리고 후보키중 기본키로 선택되지 못한키는 대체키가 된다.

유일성은 중복되는 값이 없는것을 의미한다.

최소성은 필드를 조합하지 않고 최소 필드만 써서 키를 형성할 수 있는것을 말한다.

1-7-1. 기본키

💡 기본키 (Primary Key)는 PK라고도 하며 유일성과 최소성을 만족하는 키이므로 단 한개만 존재한다.

ID	nickname
ID-0001	primary
ID-0002	int32
ID-0002	int64

PK는 테이블 데이터중 고유하게 존재하는 속성이어야 한다.

그래서 위의 ID 필드는 기본키가 되면 안된다.

ID	nickname
1	primary
2	int32
3	int32
4	boolean

하지만 위의 테이블은 ID를 기본키로 설정할 수 있다.

{ID, name}이라는 복합키를 기본키로 설정할 수도 있지만 ID만으로도 PK가 되기때문에 최소성을 만족하지 않는다.

기본키는 자연키 또는 인조키 중에 골라서 설정하게된다.

자연키

만약 유저테이블을 만든다 하면 주민번호, 이름, 성별등의 속성이 존재한다.

이중 주민번호만 중복된 값이 들어올 수 없으므로 PK로 적절한건 주민번호 뿐이다.

이런식으로 자연스럽게 중복되지 않는 값을 뽑다 나오는 키를 자연키 라고 한다.

자연키는 언젠가 변하는 속성을 말한다.

인조키

테이블을 만들때 인위적 으로 아이디를 부여하면 이를 통해 고유 식별자가 생겨난다.

오라클의 sequence, MySQL의 auto_increment 등을 사용해서 설정하게 된다.

이는 자연키와 대조적으로 절대 변하지 않기에 보통 기본키는 인조키로 설정하게 된다.

1-7-2. 외래키

💡 외래키(Foreign Key)는 FK라고도 하며, 다른 테이블의 기본키 를 참조하는 값으로 개체와의 관계를 식별하는데 사용된다.

외래키는 해당 객체를 참조해 관계를 식별하는데만 필요하기 때문에 중복되어도 상관없다.

1-7-3. 후보키

💡 후보키(candidate key)는 기본키가 될 수 있는 후보들이며, 유일성과 최소성을 동시에 만족하는 키다.

1-7-3. 대체키

💡 대체키(alternate key)는 후보키가 두개 이상일 경우 어느 하나를 기본키로 지정하고 남은 후보키를 말한다.

1-7-3. 슈퍼키

💡 슈퍼키(super key)는 각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키다.

2. ERD

💡 데이터 베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, 릴레이션 간의 관계를 정의한 것이다.

만약 서비스를 구축한다면 가장 먼저 신경써야 할 부분이다.

만약 ERD를 신경쓰지 않고 서비스를 구축한다면 단단하지 않은 골조로 건물을 짓는거나 다름없다.

ERD는 시스템의 요구사항을 기반으로 작성되고, 이를 기반으로 데이터베이스를 구축한다.

이후에도 디버깅 또는 재설계가 필요할 경우에 설계도 역할을 담당하기도 한다.

하지만 ERD는 관계형 구조로 표현할 수 있는 데이터를 구성하는데 유용할 수 있지만

비정형 데이터를 충분히 표현할 수 없다는 단점이 존재한다.

그래서 비정형 데이터는 보통 NoSQL을 사용해 저장하게 된다.

📌 비정형 데이터
데이터 베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, 릴레이션 간의 관계를 정의한 것이다.

3. 정규화 과정

💡 릴레이션간 잘못된 종속관계로 인해 데이터베이스 이상 현상이 일어나서 이를 해결하거나 저장 공간을 효울적으로 쓰기 위해 릴레이션을 여러개로 분리하는 과정이다.

3-1. 이상현상

💡 정규화를 수행하지 않아 중복이 발생하고 전체적인 무결성이 저하되어 현실세계의 실제값과 데이터베이스에 저장된 값이 일치하지 않는 문제를 말한다.

📌 무결성
현실세계 실제값과 데이터베이스에 저장된 값이 일치하는 정확성

데이터 이상은 삽입 이상, 업데이트 이상, 삭제 이상이 존재한다.

세가지 이상현상은 아래의 테이블을 사용해 설명하도록 한다.

3-1-1. 삽입 이상(Insertion anomaly)

💡 특정 데이터가 존재하지 않아 중요한 데이터를 데이터베이스에 삽입할 수 없을 때 발생한다.

위의 대학교 테이블에서 기본키는 학번 이다.

그래서 새로운 행을 삽입하기 위해서는 기본키인 학번이 필수다.

• 그런데 새로운 수학과를 개설하려 해도 학생이 존재하지 않기 때문에 테이블에 데이터를 추가할 수 없다.

이러한 현상을 삽입이상이라 한다.

이는 정규화에 의해 대학교 테이블을 학생테이블, 학과테이블로 분리하면 해결할 수 있을것이다.

3-1-2. 삭제이상(Deletion anomaly)

💡 특정 정보를 삭제하면 원치않는 정보도 삭제되는 현상이다.

• 만약 둘리학생이 자퇴해 데이터를 제거해야 하는 경우 컴퓨터공학과도 전부 삭제되게된다.

둘리 학생의 데이터를 삭제하면 컴퓨터 공학과의 나머지 정보를 특정 테이블에 저장하지 않았기에 데이터가 소멸된다.

이를 삭제 이상이라 한다.

이 문제 역시 테이블 분리로 문제를 해결할 수 있다.

3-1-3. 업데이트 이상(Update anomaly)

💡 테이블의 특정 데이터를 업데이트 했는데, 정상적으로 변경되지 않은 경우와 너무 많은 행을 업데이트 하게되는 현상이다.

만약 경영학과 학생이 100명일때 경영학과 학과장이 이름을 개명해서 학과장명을 변경해야 한다면

• 학생이 100명이므로 학과장명을 100번 변경해야한다.

만약 여기서 한개의 행이라도 변경되지 않는다면 데이터가 상이한 문제가 발생한다.

그리고 만약 학생이 1000명이면 1000개의 데이터를 변경해야하는 비효율적인 문제가 발생한다.

위의 문제는 대학교 테이블, 학과장 테이블을 분리해 문제를 해결할 수 있을것이다.

3-2. 정규형 원칙

💡 아래를 원칙을 모두 지키는것을 의미한다.

1. 같은 의미를 표현하는 릴레이션이지만 좀 더 좋은 구조로 만들어야 한다.

2. 자료의 중복성은 감소해야 한다.

3. 독립적인 관계는 별개의 일레이션으로 표현해야한다.

4. 각각의 릴레이션은 독립적인 표현이 가능해야 한다.

3-3. 제1 정규형(1 NF)

💡 릴레이션의 모든 도메인이 더이상 분해될 수 없는 원자값(atomic value)만으로 구성 되어야 한다.

릴레이션의 속성 값 중에서 한개의 기본키에 대해 두개 이상의 값을 가지는 반복 집합이 있어선 안된다.

만약 반복집합이 존재할 경우 제거해야한다.

100학번을 가진 학생이 반복집합을 가지고 있어 속성을 아래처럼 분리해주었다.

그럼에도 제1 정규형에서는 여전히 이상현상이 발생한다. 왜냐하면 기본키가 아닌 속성들이 기본키에 완전 함수 종속되지 못하고 부분 함수 종속되어 있기 때문이다.

• 위 그림을 보면 기본키는 {학번, 과목번호} 인데 지도교수, 학과가는 학번에 부분함수 종속 되어있다.

📌 부분함수 종속
기본키가 복합키일 경우 기본키를 구성하는 속성 중 일부에 종속된 경우

⛔ 제1 정규형에서 생기는 이상현상

- 삽입이상: 학생이 새 과목을 수강신청할 때 반드시 학생의 학과, 지도교수를 알아야 한다.(불필요한 정보)

- 삭제이상: 300번 학생이 C400과목을 취소하면, 해당 과목에 대한 모든 정보가 사라진다.

- 갱신 이상: 100번 학생이 지도교수를 변경할 때, P1인 행을 모두 찾아서 변경해줘야 한다.

3-4. 제2 정규형(2 NF)

💡 제1 정규형을 만족하고, 기본키에 속하지 않는 속성 모두가 기본키에 완전 함수 종속인 정규형이다.

부분함수 종속 되어있는 속성을 제거해주기 위해 릴레이션을 두개로 분리해준다.

이때 주의할점은 릴레이션을 분해할 때 동등한 릴레이션으로 분해 해야하고, 정보손실이 발생하지 않는 무손실 분해로 분해되어야 한다.

• 이렇게 나눠줌으로 인해 각 속성이 모두 완전 함수 종속이 되었다.

하지만 아직도 이상현상이 존재한다.

제2 정규형에서 이상현상이 여전히 발생하는 이유는 이행적 함수 종속성 때문이다.

📌 이행적 함수 종속성
속성이 A→B 이고, B→C 이면서, A→C 관계에 있는것을 말한다.

위의 예제는 학번→지도교수, 지도교수→학과, 학번→학과의 간계가 존재한다.

따라서 지도교수의 학과를 추가하려면 지도 학생도 필요하고, 학생이 자퇴했는데 지도교수의 학과정보도 함께 사라지는 문제가 생긴다.

⛔ 제2 정규형에서 생기는 이상현상

- 삽입이상: 지도교수가 학과에 소속되어 있음을 추가할 때 반드시 지도학생이 있어야 한다.(불필요한 정보 필요)

- 삭제이상: 300번 학생이 자퇴하면 P3 교수의 학과정보가 사라진다.

- 갱신 이상: 지도교수의 학과가 변경되는 경우 모두 찾아서 변경해줘야 한다.(지도교수가 동일한 학생이 여러명 있는경우)

3-5. 제3 정규형(3 NF)

💡 제2 정규형을 만족하고, 이행적 함수 종속성 을 제거한 정규형을 말한다.

즉, 기본키에 속하지 않은 모든 속성이 기본키에 이행적 함수 종속이 아닐 때 제3 정규형 이라고 한다.

다른말로 표현하면 기본키 이외의 속성이 그 외 다른 속성을 경정할 수 없는것이다.

• 이행적 함수 종속관계에 있는 속성을 분리한다.
  

3-6. BCNF(Boyce and Codd Normal Form)

💡 제3 정규형을 조금 더 강화한 개념으로 강한 제3 정규형이라고도 불린다.
결정자가 후보키가 아닌 함수 종속 관계를 제거해 릴레이션의 함속 종속 관계에서 모든 결정자가 후보키인 상태를 말한다.

• 위 릴레이션은 제3 정규형을 만족한다.
• 이행적 함수 종속성이 존재하지 않기 때문이다.
• 하지만 이상현상이 발생한다.

이상현상이 발생하는 이유는 결정자가 후보키 취급을 받지 못하기 때문이다.

후보키는 슈퍼키중 최소성을 만족하는 키 이므로 위 릴레이션에서는 {학번, 과목명}, {학번, 담당교수}가 후보키가 되며, 담당교수 만으로는 후보키가 될 수 없다.

하지만, 후보키가 아님에도 과목명을 결정할 수 있기에 담당교수는 결정자에 속한다.

이상현상을 해결하기 위해 모든 결정자는 항상 후보키가 되도록 릴레이션을 분리해주면 BCNF를 만족하게 된다.

⛔ 제3 정규형에서 생기는 이상현상

- 삽입이상: 새로운 교수가 특정 과목을 담당한다는 정보를 추가할 수 없ㄷ. 적어도 한 명 이상의 수강 학생이 필요한다.

- 삭제이상: 학번 100이 C234 과목을 취소하면, P2가 C234 과목을 담당한다는 정보도 삭제된다.

- 갱신 이상: P1 과목이 변경되면 P1인 행을 모두 찾아 변경시켜 줘야한다.

4. 조인

💡 하나의 테이블이 아니라 두 개 이상의 테이블을 묶어 하나의 결과물을 만드는걸 뜻한다.

MySQL에서는 JOIN이라는 쿼리로, MongoDB에서는 lookup이라는 쿼리로 이를 처리할 수 있다.

그런데 MongoDB의 조인연산은 RDB에 비해 성능이 떨어지기에 테이블을 조인하는 작업이 많을경우 RDB를 써야한다.

조인의 대표적인 종류는 내부 조인, 왼쪽 조인, 오른쪽 조인, 합집합 조인이 있다.

다음의 예제에서는 아래의 테이블을 사용하도록 하겠다.

SELECT * FROM student;

SELECT * FROM subject;

4-1. 내부조인(Inner join)

💡 두 테이블간의 교집합을 나타낸다.

• inner join은 교집합 연산과 같다. 조인 키 컬럼 값이 양쪽 테이블 데이터 집합에서 공통적으로 존재하는 데이터만 조인해서 결과 데이터 집합으로 추출하게 된다.

SELECT * FROM student A 
INNER JOIN subject B 
ON A.ID = B.student_id;

• student 테이블과 subject 테이블에 키 컬럼 값이 모두 존재하는 데이터만 나오는걸 볼 수 있다.

4-2. Left outer join

💡 테이블 A를 기준으로 (A ∩ B)의 결과를 나타낸다.
( (A ∩ B) ∪ (A - B) )와 같다.

SELECT * FROM student A 
LEFT JOIN subject B 
ON A.ID = B.student_id;

• student에는 STDT-005가 존재하는데 subject 에는 존재하지 않아서 subject 부분이 NULL로 나오는걸 볼 수 있다.

4-3. Right outer join

💡 테이블 B를 기준으로 (A ∩ B)의 결과를 나타낸다.
( (A ∩ B) ∪ (B - A) )와 같다.

SELECT * FROM student A 
RIGHT JOIN subject B 
ON A.ID = B.student_id;

• 이번엔 반대로 suject에는 STDT-004가 존재하는데 student에는 STDT-004가 존재하지 않아서 NULL로 나오는걸 볼 수 있다.

4-4. Full outer join

💡 두 테이블간의 합집합 연산과 같다.
공통의 데이터, 한쪽에만 존재하는 데이터 모두 결과 집합으로 추출하게 된다.

SELECT * FROM student 
LEFT JOIN subject 
ON student.ID = subject.student_ID
union 
SELECT * FROM student 
RIGHT JOIN subject 
ON student.ID = subject.student_ID;

• 다른 DBMS에서는 FULL OUTER JOIN을 사용하면 되지만 mysql에서는 이를 지원하지 않기에 left join, right join 한 값을 union으로 합쳐야한다.

4-5. 조인의 원리

위의 조인은 중첩 루프 조인, 정렬 병합 조인, 해시 조인을 기반으로 조인을 하게 된다.

4-5-1. 중첩 루프 조인(Lested Loop Join, NLJ)

💡 중첩 for문과 같은 원리로 조건에 맞는 조인을 하는 방법이다.
랜덤 접근에 비용이 많이 증가하므로 대용량의 테이블에서는 사용하지 않는다.

예를들어 t1, t2 테이블을 조인한다 라고 했을때
첫 번째 테이블에서 행을 한번에 하나씩 일고 그 다음 테이블에서도 행을 하나씩 읽어 조건에 맞는 레코드를 찾아 결과를 반환한다.

for key_a in table_a:
	for key_b in table_b:
		if key_a == key_b:
			set.add(row)

• 위처럼 테이블을 하나하나 보며 키가 일치한다면 집합에 포함하는 식이다.

4-5-2. 정렬 병합 조인

💡 각각의 테이블을 조인할 필드 기준으로 정렬 후 조인 작업을 수행하는 조인이다.

조인할 때 쓸 적절한 인덱스가 없고 대용량의 테이블들을 조인하고 조건으로 >, < 등 범위 비교 연산자가 있을 때 사용한다.

조인 순서는 아래와 같다.

1. 선행 테이블에서 조건에 맞는 키를 찾은 후 정렬한다.
2. 후행 테이블에서 조건에 맞는 키를 찾을 후 정렬한다.
3. 조인을 수행 후 성공하면 결과를 반환한다.

4-5-3. 해시조인

💡 해시 테이블을 기반으로 조인하는 방법이다.

두 개의 테이블을 조인한다고 했을 때 하나의 테이블이 메모리에 온전히 들어갔을 경우 보통 중첩 루프 조인보다 더 효울적이다.

하지만 메모리에 올릴 수 없을정도로 크다면 디스크를 사용하기에 성능이 저하될수도 있다.

MySQL에서 해시 조인 단계는 빌드, 프로브 단계로 나뉜다.

빌드 단계

💡 입력 테이블중 하나를 기반으로 메모리 내 헤시 테이블을 빌드하는 단계

두개의 테이블중 바이트가 더 작은 테이블을 기반으로 테이블을 빌드한다.

• countries.country_id가 해시 테이블의 키로 사용돼 레코드가 저장된다.

프로브 단계

💡 프로브 단계동안 레코드를 읽기 시작하며, 각 레코드에서 ‘person.country_id’에 일치하는 레코드를 찾아 결과로 반환한다.

이를통해 각 테이블은 한번씩만 읽게 되어 중첩 루프 조인보다 보통은 성능이 좋다.

끝!

이제 부스트캠프 챌린지도 사실상 이틀밖에 남지 않았습니다.
마지막이 다가올수록 늘어지는 느낌이 있는것같아서 내일은 스스로 난이도를 조금 높이려 합니다.

함께 자라기 라는 책을 읽고 느낀점, 배운점이 많은데 집중할 수 있는 난이도를 찾는것도 중요했습니다.
너무 쉬우면 쉬워서 집중이 안되고 어려우면 어려워서 집중이 안되기 때문입니다 ㅋㅋㅋㅋ!

어려운건 어려운거고 쉬운건 쉬운겁니다. 왜냐하면 그게 난이도니까.

지금까지 3주라는 시간이 진짜 순식간에 없어진것 같습니다.
맨날 미션을 수행하고, 팀원들을 만나고, 또 미션하고 밥먹고 잠도좀 자고 이러니까 벌써 8월이네요

오늘 특이한 코드를 봤는데 함수형으로 작성된 코드였습니다.
이런식으로 작성된 코드는 처음 봤는데 확실히 가독성이 매우 좋았습니다. 이해하는건 둘쨰치고요
저도 이번 네부캠 챌린지가 끝나면 꼭 함수형 프로그래밍을 배워보려 합니다.

아 그리고 이번에 퀘스트를 하나 받았는데 작년의 내가 뭘했는지에 대해 적는거였습니다.

그런데 정확히 7/31과 8/1에 적은 글만 없어서 비슷한 날에 적은 글로 대체하겠습니다!

• 2022/07/28 (목)
  • 글: https://velog.io/@song961003/vscode-extension-%EA%B0%9C%EB%B0%9C
  • 글에서 시작부터 파일 만들기가 귀찮다고 하고있습니다.
    아마 이 때 반복적으로 같은 파일을 만들고 같은 내용을 적는것을 상당히 귀찮아 했던것 같습니다.
    그래서 vscode의 extension을 개발했습니다.
    예전에도 지금도 저는 귀찮은걸 매우 매우매우매우 매우 싫어해서 귀찮은 상황을 없애버립니다.
    설거지가 매우 귀찮으면 설거지를 없애버리는 식으로요.
    그런데 이 때 공식 문서밖에 잘 설명되어 있는 글이 영어로만 검색을 했던것같은데 아직도 영어 실력이 늘지를 않습니다... 꼭 잘해보고 싶습니다.
• 2022/07/30 (토)
  • 글: https://velog.io/@song961003/ToyProject-%EA%B0%80%EA%B3%84%EB%B6%80-1
  • 이때는 처음 커뮤니티에서 팀원을 구해서 프로젝트의 구상을 해본 날 같습니다. 엄청 들떠서 태블릿에 열심히 그림도 그리고 글도 썼던것 같은데 여전히 악필이네요... 이 프로젝트는 1달정도 걸린것같은데 거의 혼자서 대부분을 구현 했던걸로 기억납니다. 그래서 이 다다음 프로젝트에서는 약간 흥미? 관심? 애정? 그런게 떨어졌습니다. 하지만 금방 원래대로 돌아오긴 했어요. 그리고 이 때 만난 스터디원과는 아직도 스터디를 하고있습니다. 프로젝트 개발하는 방향이 아니긴 하고, 팀원도 중간에 몇번 바뀌긴 했지만 아직도 재밌게 하고있는것같아요.

그럼 예전에 썼던 글에대한 리뷰를 적은걸 끝으로 마무리 하겠습니다! 🖐️