정규화가 반드시 필요할까?

프로젝트를 진행하며 정규화를 시키지 않고 아래와 같이 테이블을 구성했는데요, 이에 대해 고민했던 사항에 대해 간략하게 공유해보겠습니다. ** 물론 대부분의 상황에서 정규화는 중요하고 필요하지만 이렇게 생각할 수도 있구나 하는 정도로 가볍게 읽어주시면 감사하겠습니다.

 

 

 

 

 

 

1. 현재 상황 및 구현

---

하루에 실천할 계획을 최대 5개까지 등록할 수 있도록 엔티티(테이블)를 만들고 싶었는데 각 컬럼들을 정규화 시키지 않고 First, Second, Third, Fourth, Fifth로 두고 구현했습니다. 만약 정규화를 한다면 각 컬럼들을 별도의 엔티티로 분리해줘야 합니다. 

 

 

 

 

 

 

 

즉 정규화를 거치면 아래와 같이 하나의 계획에는 각각의 목표들이 일대다로 대응돼야 하며, 테이블이 두 개로 나뉘어지고 데이터를 찾아오기 위해서는 조인을 걸어야 합니다. 

 

 

 

 

그런데 이렇게 되면 하나의 DailyPlan에 대해 5개의 로우(DailyPlanGoal)가 만들어지게 되는데 과연 이게 옳을까? 에 대한 의문이 들었습니다. 매번 (최대)5개씩 로우가 생성되고 조인을 통해 데이터를 찾아야 하기 때문에 비효율적으로 데이터가 관리될 것 같았기 때문입니다. 그래서 비록 한 테이블에 중복된 컬럼들은 발생하지만, 정규화는 위배하지만 하나의 엔티티에 5개의 필드를 모두 넣고 사용하자라고 클라이언트와 협의를 보게 되었습니다. 이렇게 되면 컬럼에는 null 값이 들어올 수 있지만 조회할때 별도의 조인이 없이 데이터를 빠르게 찾아올 수 있기 때문입니다. 

 

 

물론 이 과정에서 추가되는 값이 얼마가 될지 알 수 없기 때문에 목표가6개, 7개, 8개, 9개 .... 등 계속해서 증가한다면 하나의 테이블이 너무 거대해지고 그 과정에서 컬럼에 null 값이 많이 들어갈 수 있는 단점이 존재합니다. 하지만 이 테이블은 그렇게 컬럼이 많이 늘어날 확률이 적다고 판단했고 조회 과정에서 얻을 수 있는 장점이 그보다 더 크다고 판단해 결국 위 선택을 하게 되었습니다. 

 

 

 

 

 

2. Conclusion

---

별 내용이 없었는데 결론은 정규화는 중요하지만 자신의 상황에 맞게 구현/설계하는 것이 더 중요하다 입니다. 최근 개발에는 정답이 '잘' 없다 는 것을 정말 많이 느끼는데요, 올바른 방법은 존재하지만 자신의 상황과 다르다면 그 방법이 최선은 아닐수도 있기 때문입니다. 정규화를 시키지 않더라도, 중복된 컬럼이 존재하더라도 조금만 바꾸면 운영상 편리해지는 부분이 있기 때문에 이러한 부분에 대해서는 적절한 타협이 필요한 것 같습니다.