안녕하세요.
2cpu에 디비 관련 질문을 해도 되는지 모르겠습니다.
그러나 다른 커뮤니티들에 비해 이곳이 전문가 분들이 더 많이 계시는 것 같아서 질문을 남겨봅니다.
예전에 제가 대학교 다닐 때에는 디비 수업 시간에 정말 어쩔 수 없는 경우가 아니라면 null 값은 피해야 한다고 배웠습니다.
그리고 대부분의 null 값은 테이블 정규화를 통해서 없애는 것도 배웠고요... (물론 지금은 찾아보면서 해야합니다.)
그러다가 비교적 최근에 회사(작은 회사입니다...)에서 디비 테이블을 봐야 할 일이 있어서 디비 담당자분께 요청해서 디비 테이블을 봤습니다.
테이블이 여러개 있었는데 테이블마다 null 값이 제법 자주 들어있었네요.
그 때 그 때마다 추가로 필요한 속성 값이 있으면 개의치 않고 테이블에 컬럼을 추가하는 것 같았습니다.
별로 정규화를 시킨 것 같지도 않았고요... (사용하는 디비가 관계형이었습니다.)
이래도 되냐는 제 물음에 담당자들은 물론 다른 직원들도 별 문제 없지 않냐는 식으로 시큰둥한 반응이었네요.
여기서 궁금증이 생겼습니다.
학교에서 배운 것은 말 그대로 그냥 학교에서 배운 것일 뿐, 실제 현업에서는 테이블 정규화는 별로 개의치 않고 사용하는 경우가 잦은 편인가요?
요즘에는 추세가 굳이 관계형에서도 정규화를 하지 않고 쓰는 것인지 어떤 것인지 궁금합니다...
- 네 일부는 맞습니다.
DBA가 없는 경우로 개발되는 경우도 많고, 개발, 개선이 계속 진행되면서 변경 사항이 많기 때문에
(도메인 분석이 잘못 되는 경우, 현업의 수준과 개발자가 아직 업무 파악에 미숙한 경우, 사업 및 업무가 계속 변경되는 경우 등등)
NULL 값을 포함하거나 필드값을 여유 있게 만들어 두고 사용합니다.
운영중에 DB 필드를 추가하는게 더 리스크 합니다.
저는 정규화 되면 많은 이점이 있다고 봅니다.
그런데 프로그램 하는 입장에서는 불편한 Join등을 해야해서 싫어 합니다.
조직에 DA가 있는 경우도 적고
프로젝트가 시일이 촉박하게 진행되어
표준이 무시되는 경우도 많아서 그렇습니다.
최초 개발시 정규화는 필수지만 유지보수중엔 왠만하면 추가로 정규화 하진 않네요.
NULL은 피해야 하지만 주로 소스에서 해결합니다.
이유는 NULL 과 문자열 조합과 연산이 불가능하고 문자를 다루는 함수에서 에러가 나는것이 주요 이유인데요.
그런데 DB에서 가져오는 모든 부분에 NULL을 블랭크로 변환해서 변수에 담는 함수를 사용하면 문제가 사라져서 자연스레 DB에선 피할 필요가 없게 되네요.
NULL이 많으면 DB 성능이 낮아진다지만 사실 가로 폭이 늘어날 수록 속도가 많이 느려집니다.
그래서 NULL을 제거하면서 가로 폭을 줄이려는 것인데 여러 소스에서 해당 컬럼을 호출하는 상황에 이를 일일이 변경하는 업무량이 너무나 많아서 컬럼을 늘리는 것으로 끝냅니다.
교집합과 합집합의 관계에서 반복을 제거하면서 공통값으로(키) 연결하는것이 필수지만 너무 빈번하게 Join 하면 그냥 1개 테이블로 합치는것도 자주 합니다.
결국 속도가 더 빠르기도 해서요.
개발자 PC에서 여러번 테스트하는 속도는 무의미합니다. 이미 DB캐시에 들어가 버려서요.
여러 유저들이 여러 레코드를 호출과 조인하는 상황에서 프로파일러로 지켜보며 튜닝하면 결국엔 1개 테이블이 빠를때도 종종 있습니다.
1-3차 정규화에 BCNF 까지 해도 궁극적으론 속도와 안정성을 위한 것인데 요즘엔 서드파티 라이블러리가 많이 도와줘서 DB는 단순화 하는게 유행이더라구요.
그래도 저는 꿋꿋이 조인과 그룹바이를 많이 사용합니다. 평상시엔 모르지만 사고 터지면 원인 찾는것과 복구가 훨씬 수월하니까요.
실무에서 DB는 대부분 PK와 FK 관계를 맺게됩니다. 즉 관계를 맺는 PK는 null이 존재하면 안되는건데(데이터 정합성위반) 아마 위 설명을 뒷받침 해주고 있습니다.
null은 없어도 크게 성능상이나 기타 문제가 되지는 않으나 관계형일때는 반드시 필수조건을 만족해야 됩니다.
흠 학교다닐때 잘 가르켜준거 같네요.