[도서 회고록] SQL Antipattern 을 읽고

오랜만에 책을 한 권 읽었다.

 

사실 해당 책을 산지는... 3년이 넘은 것 같다. 

 

한창 inflearn에서 강의를 열심히 들을 때였다. 

 

그 유명한 한국 Spring의 스타강사인 김영한씨께서 추천을 했던 책이다.

 

 

SQL AntiPatterns! 라는 책으로 개발자가 알아야 할 25가지 SQL함전과 해법!

 

이라고 소개하고 있다.

 

해당 책의 목차를 쭈욱! 적어보고, 필자가 인상깊게 읽었던 부분에 대해 생각하려고 한다.

 

1. 해당 책에서 소개한 안티패턴

무단횡단

순진한 트리

아이디가 필요해

키가 없는 엔트리

엔터티-속성-값

다형성 연관

다중 칼럼 속성

메타데이터 트리블

 

반올림 오류

31가지 맛

유령 파일

인덱스 샷건

 

모르는 것에 대한 두려움

애매한 그룹

임의의 선택

가난한 자의 검색 엔진

스파게티 쿼리

암묵적 칼럼

 

읽을 수 있는 패스워드

SQL인젝션

가상키 편집증

나쁜 것 안 보기

외교적 면책특권

마법의 콩

 

정규화 규칙과 참고문헌 

 

 

여기서 필자가 가장 재미있게 봤던 부분은 무단횡단, 엔터티-속성-값, 다형성 연관, 다중 칼럼 속성이다.

 

사싥 이거 다 읽어봐도 금방 잃어버린다.

 

다만 필자가 느낀 핵심은 다음이었다.

 

2. 정규화 복습하기

결국 올바르게 데이터를 넣기 위해서는 정규화를 잘해야 한다. 

 

이게 괜히 나온게 아니다 정말!

 

간단하게 이야기 하고 가자.

 

2.1) 제1 정규화

컬럼에 여러개 들어가지 않게 데이터를 잘 쪼갠다.

이걸 이쁘게 말하면 속성 하나는 하나의 속성값만을 가져아 한다 는 말이다.

 

예를 들어, 하나의 row 중 한 컬럼에 수학, 과학으로 데이터가 들어가있다면 값이 여러개가 들어간 것이다.

 

2.2) 제2 정규화

특정 데이터에만 종속하면 별도 테이블로 분리한다.

이걸 멋지게 포장해보면 기본키 중 특정 컬럼에만 족송된 컬림이 존재할 경우 라고 한다.

즉, 성격이 다른건 나누는것이다.

 

2.3) 제3 정규화

이행적 종속을 없앤다. 말조차 어렵다.

 

데이터가 들어가는데 순서가 row에 생겨버린다! 그러면 이를 테이블로 분리한다.

 

순서가 생긴다포 필자가 표현한 것은 X->Y, Y->Z인데 X->Z를 만족하는 것이다. 이를 하면 안됀다는 것이다.

 

가장 많이 보이는 예로는 고객정보 테이블에 등급과 할인율이 있는 경우다. 

 

고객정보를 받아서 등급을 넣고 할인율을 넣엇는데, 이상하게 고객정보를 통해 할인율이 정해지는것으로 보인다.

 

2.4) BCNF 정규화

모든 결정자가 후보키가 되도록 한다. 예를 들어, 학생과 과목 그리고 교수가 있다면 ... 학생과 과목, 과목과 교수로 나누는 것이다. 

 

2.5) 제 4정규화

다치 종속을 제거한다. 

다치종속? 말부터 어렵네... 같은 테이블 내의 독립적인 두 개 이상의 컬럼이 또 다른 컬럼에 종속되는 것 이라고 한다. 

 

2.6) 제 5정규화

제 5정규화는 4정규형을 만족하는 테이블에 대해 조인 종속을 제거하는 것을 의미한다.

 

3. 무단횡단, 엔터티-속성-값,다형성 연관, 다중 칼럼 속성

SQL AntiPatterns Tips!

1) 각 값은 자신의 칼럼과 행에 저장하라.

2) 메타데이터를 위해서는 메타데이터를 사용하라!

3) 모든 테이블 관계에는 참조하는 테이블 하나, 참조되는 테이블 하나가 있다.

4) 같은 의미를 가지는 각각의 값은 하나의 칼럼에 저장하라.

 

솔직히 다른 문제들은 잘 모르겟는데, 4개의 문제들은 꼭 기억을 하고 넘어가야겟다는 생각이 들었다.

 

문제의 시발점은 테이블을 여러개 생성하지 않고, 속성값을 저장해서 화면상에 그려주겠다는 것이다.

 

메타데이터를 저장하고, 이 메타데이터에 대한 상세 값도 저장하고 화면을 동적으로 생성해주자는 것이 골자다.

 

 

여기서 우선 무단횡단 문제가 발견되었다.

 

사이트의 버전에 따라서 다양한 코드를 table에 넣어두는데, 이것을 ,,,,... 이렇게 해버린 것이다. 

 

그러면 자연스럽게 db에서 다른 작업이 쓸데없이 많아지고 파악도 어렵다. 

 

그럴바에는 별도의 테이블을 하나 두고 1 - N : N - 1 관계로 확장하는것이 좋다고한다.

 

 

EVA(Entity-Attribute-Value)를 통해서는 무한히 화면을 생성한다는 것이다. 테이블의 증가 없이 가변 속성을 지원하는 것이다. 

 

해법으로는 그냥 올바르게 정규화를 통한 올바른 테이블을 만드는것이 맞다고 생각한다. 

 

이렇게 설계를 안하고 날로 먹으려 하니.. 성능적으로도 문제가 생기고 데이터 검증도 어려워 지기 때문에 저자는 서비스 시작 후 1년안에 정말 힘들어질거라고 장담한다.

 

 

다형성 연관은 특정 table의 FK가 상황에 따라 다른 테이블을 바라보는 것이다.

 

이것의 문제는 DB에서 제공하는 기능을 사용하지 못해 최대한 끌어올리지 못하며 데이터 조회시에도 상황에 따라 다르기에 

 

union을 쓰고 또 join해서 가져와도 null로 비어버린 데이터를 봐야만 한다. 

 

 

다중 칼럼 속성은 데이터를 row로 쌓는게 아니라 이게 싫어서 컬럼을 늘려서 쌓는 것이다. 

 

후에는 얼마나 늘어날 지 모르고, 늘어나는 수에 따라서 검색시 where 조건도 계~ 속 늘어난다.

 

4. 나의 회고록 (단점과 장점)

 

이전의 회사에서도 비슷한 문제있었는데, 현재 회사에서도 해당 문제에 직면했다.

 

빠르고 쉽게 DB를 확장 가능하게 만들수 있을까? 개발이 너무 편해지고 빠르고 막힘이 없을 것 같은데? 하는 생각 말이다.

 

그래서 no-coding같은 것을 만든다던가, EVA테이블로 덕지덕지 작업을 한다던가 하는 문제에 빠지게 되었다. 

 

단점

필자도 사실 좋다고 생각했다. 그러한 생각과 도전의식에 동의했고 우선은 잘 따랐다.

 

하지만 현 시점에서 EVA를 도입함으로써 지옥이 시작됐다.

 

 

DB에 있는 기능을 제대로 이용하지 못할 뿐더러 쌓여가는 난해한 데이터들을 어떻게 관리할지, 이것이 맞는지 곤란한 상황이 왔다.

 

무엇보다도 매일 정리하고 봐도 몇일 뒤 보면 기존의 통념과 다른 테이블 모습과 이럴때는 데이터를 이렇게 넣고, 이럴때는 데이터를 이렇게 넣는 요상하고 복잡한 상황에 지쳐가는 나를 발견했다.

 

 

빠른 개발속도와 적은 프로시저 개발 공수는 정말 꿈처럼 왔지만, 이는 결국 어딘가로 기술 부채를 떠넘기는 행위였다.

 

힘들어지는건 결국 실제로 화면을 구성하고 API를 만들고 두번 세번 이 아닌 10번은 족히 고민하고 개발하는 개발자 (나 ㅠㅠ) 였다.

 

그래서 내가 도대체 왜 이런 일이 발생했나? 나도 좋다고 생각했는데 점점 뭐가 이상하다.

 

 

현재 어느 상황에서 PK로 사용해야하고, Unique를 사용해야 하는지 혼동되는 점

즉, 비즈니스 데이터를 자연키로 사용하는 잘못된 설계가 Gemini와의 대화를 통해 잘못되었다는 점도 있었지만

 

설마 이게 안티패턴...? 하고 안돼! 하고 책을 펴봤더니 위에 보인 것들이 또 잘못되었다는 점을 알게 되었다. 

 

 

결국에는 DB정규화를 잘 따라간 후에, 너무 자주 조회되는 데이터의 경우에는 반정규화를 통해 함께 관리하는게 가장 빠르고, 정석적이며 후에 문제가 없다고 생각한다.

 

장점

쿼리를 작성하는데 이상하게 조인을 할 일이 없다. 

 

내가 이토록 조인을 안하게 되는 일이 있었나?

 

사실 현재 회사에서 조인을 하는 일이 정~~~말 없다.

 

아무리 개발중이고 간단하다고 해도 그렇지 이렇게 단순화하면 개발 속도는 빠르고 당장 속은 편한거같긴 하다.

 

---

 

지금 AI기술은 정말 하루가 다르게 미친듯이 발전하고 있다.

 

현재 글을 적는 시점에서 가장 큰 이슈는 하네스 엔지니어링이다. 

 

AI에게 가이드라인을 제시해 원하는대로 작업하도록 도와주는 방식인데, 미친듯한 퍼포먼스를 보여줄 수 있는 

 

이러한 시대에도, 사실 사용하면 사용하는거지 기초의 중요성인 아무리 강조해도 중요하다!

 

 

해당 프로젝트에서 왜 그러면 안되는지 몸소 체험하고 정말 공부하고자 하는 욕심이 빠르게 책을 읽게 도와주었다.

 

막상 책을 읽어보니 너무 당연한거 같다. 하지만 실전은 늘 그렇지 않더라... 당연하다 생각하는게, 당연하지 않는 경우가 많다.

 

 

많은 일을 하다 보면 현실과 타협을 하는 경우가 많다. 

 

내가 책임자라면 이렇게 안햇겠지만, 애초에 제품 설계 단계부터 중,소 사업장을 위한 틈새 시장 공략용 제품이기에 사실 정규화 자체가 오버엔지니어링으로 판단했고 그렇기에 다른 쪽에 집중하는것으로 보인다.