🔴 [규칙 4] 데이터 중복이 발생하는 컬럼이 있는지 확인해보자!
✅ 데이터 중복이 발생하는지 값을 넣어보면된다.
posts(게시글)
| id(PK) | 제목 | 내용 | 작성자 |
|---|
| 1 | node.js 정보 | 내용1 | 호날두 |
| 2 | OSI 7계층 | 내용2 | 호날두 |
| 3 | HLS 와 RTMP | 내용3 | 호날두 |
- posts 테이블에 작성자가 "호날두"라는 이름이 중복되었다. 만약 호날두가 아이패두로 개명한다면 해당하는 게시글에 작성자를 전부 일일이 고쳐야한다.
- 게시글이 예시처럼 3개만 있으면 고쳐보겠지만 몇십만, 몇백만개가 있다고 생각해보면 거의 불가능에 가깝다. 어떻게 해결할까?
😇 중복이 발생하는 컬럼을 테이블 분리로 해결한다.
posts(게시글)
| id(PK) | 제목 | 내용 | 작성자 id(FK) |
|---|
| 1 | node.js 정보 | 내용1 | 1 |
| 2 | OSI 7계층 | 내용2 | 1 |
| 3 | HLS 와 RTMP | 내용3 | 1 |
users(사용자)
- 중복이 발생하는 작성자 컬럼을 users라는 테이블로 분리해서 참조하게 만들면 일일이 수정할 필요없이 users테이블에 작성자 데이터만 바꾸면 게시글의 작성자가 전부 바뀌게 된다.
🔴 [규칙 5] 가짜 중복과 진짜 중복을 구별해라.
👀 가짜 중복과 진짜 중복이 무슨 뜻일까?
posts(게시글)
| id(PK) | 제목 | 내용 | 작성자 |
|---|
| 1 | node.js 정보 | 내용 | 호날두 |
| 2 | node.js 정보 | 내용 | 호날두 |
| 3 | node.js 정보 | 내용 | 호날두 |
호날두라는 작성자가 같은 제목과 같은 내용의 게시글을 3개 작성했다고 생각해보면 테이블을 봤을 때 제목 , 내용, 작성자 전부가 중복처럼 보인다. 하지만 진짜 데이터 중복은 작성자 컬럼만 발생한다.
😅 가짜 중복인지 진짜 중복인지 어떻게 구별해?
- 실제 서비스에서 A 데이터의 값을 수정하면, B 데이터의 값도 같이 수정해야 하는가? 를 생각해보면 된다.
posts(게시글)
| id(PK) | 제목 | 내용 | 작성자 |
|---|
| 1 | node.js 정보 | 내용 | 호날두 |
| 2 | node.js 정보 | 내용 | 호날두 |
| 3 | node.js 정보 | 내용 | 호날두 |
- 1번 게시글의 작성자 이름을 수정하면, 2번 게시글의 작성자도 변경되어야
하는가? -> Yes (진짜 중복)
- 1번 게시글의 제목을 수정하면, 2번 게시글의 제목도 같이 수정되어야
하는가? -> No (가짜 중복)
- 1번 게시글의 내용을 수정하면, 2번 게시글의 내용도 같이 수정되어야
하는가? -> No (가짜 중복)
진짜 중복을 찾았으면 진짜 중복의 컬럼에 대해서 테이블을 분리한다.
users(사용자)
🔴 [규칙 6] 숨어있는 중복을 찾자.
🎁 숨어있는 중복이 뭔지 예시를 통해 알아보자.
posts(사용자)
| id | 제목 | 내용 | 좋아요 수 | 사용자 id(FK) |
|---|
| 1 | 제목1 | 내용1 | 2 | 1 |
users(사용자)
likes(좋아요)
| id | 사용자 id(FK) | 게시글 id(FK) |
|---|
| 1 | 1 | 1 |
| 2 | 2 | 1 |
- 위의 예시에서 중복 데이터가 발생하는 컬럼이 없다. 하지만 숨어있는 중복이 있다.
- 2번 사용자가 1번 게시글의 좋아요를 삭제했다고 생각해보면
likes테이블에서 데이터만 삭제하면 될 것 같지만 posts에서 좋아요 수의 값도 변경해야한다. 결국에 특정 데이터를 수정할 때, 다른 데이터도 같이 수정해줘야 하는 상황이다.
- 이런 경우를 숨어있는 중복이라고 한다.
👀 어떻게 해결할까?
posts 테이블에서 좋아요 수 컬럼을 없애고 likes테이블에서 좋아요 수를 집계함수를 써서 카운팅 하는 방법이 있다.
참조
