이현석1 2021-02

학교에서 배운 것은 말 그대로 그냥 학교에서 배운 것일 뿐, 실제 현업에서는 테이블 정규화는 별로 개의치 않고 사용하는 경우가 잦은 편인가요?
  - 네 일부는 맞습니다.
 DBA가 없는 경우로 개발되는 경우도 많고, 개발, 개선이 계속 진행되면서 변경 사항이 많기 때문에
(도메인 분석이 잘못 되는 경우, 현업의 수준과 개발자가  아직 업무 파악에 미숙한 경우, 사업 및 업무가 계속 변경되는 경우  등등)
NULL 값을 포함하거나 필드값을 여유 있게 만들어 두고 사용합니다.
운영중에 DB 필드를 추가하는게 더 리스크 합니다.

배고프고가… 2021-02

이현석1님 정말 감사합니다. 많은 도움이 되었습니다.

DAP박인호 2021-02

우리나라에서 표준화, 정규화, 현행화 되어 관리되는 곳을 찾기 힘들어요.
저는 정규화 되면 많은 이점이 있다고 봅니다.
그런데 프로그램 하는 입장에서는 불편한 Join등을 해야해서 싫어 합니다.
조직에 DA가 있는 경우도 적고
프로젝트가 시일이 촉박하게 진행되어
표준이 무시되는 경우도 많아서 그렇습니다.

배고프고가… 2021-02

DAP박인호님 정말 감사합니다. 많은 도움이 되었습니다.

이대호 2021-02

소프트웨어 회사에서 대학교 DB만 20년 해 본 경험으론 
최초 개발시 정규화는 필수지만 유지보수중엔 왠만하면 추가로 정규화 하진 않네요.
NULL은 피해야 하지만 주로 소스에서 해결합니다.
이유는 NULL 과 문자열 조합과 연산이 불가능하고 문자를 다루는 함수에서 에러가 나는것이 주요 이유인데요.
그런데 DB에서 가져오는 모든 부분에 NULL을 블랭크로 변환해서 변수에 담는 함수를 사용하면 문제가 사라져서 자연스레 DB에선 피할 필요가 없게 되네요.
NULL이 많으면 DB 성능이 낮아진다지만 사실 가로 폭이 늘어날 수록 속도가 많이 느려집니다.
그래서 NULL을 제거하면서 가로 폭을 줄이려는 것인데 여러 소스에서 해당 컬럼을 호출하는 상황에 이를 일일이 변경하는 업무량이 너무나 많아서 컬럼을 늘리는 것으로 끝냅니다.
교집합과 합집합의 관계에서 반복을 제거하면서 공통값으로(키) 연결하는것이 필수지만 너무 빈번하게 Join 하면 그냥 1개 테이블로 합치는것도 자주 합니다.
결국 속도가 더 빠르기도 해서요.
개발자 PC에서 여러번 테스트하는 속도는 무의미합니다. 이미 DB캐시에 들어가 버려서요.
여러 유저들이 여러 레코드를 호출과 조인하는 상황에서 프로파일러로 지켜보며 튜닝하면 결국엔 1개 테이블이 빠를때도 종종 있습니다.
1-3차 정규화에 BCNF 까지 해도 궁극적으론 속도와 안정성을 위한 것인데 요즘엔 서드파티 라이블러리가 많이 도와줘서 DB는 단순화 하는게 유행이더라구요.
그래도 저는 꿋꿋이 조인과 그룹바이를 많이 사용합니다. 평상시엔 모르지만 사고 터지면 원인 찾는것과 복구가 훨씬 수월하니까요.

배고프고가… 2021-02

이대호님 정말 감사합니다. 많은 도움이 되었습니다.

술이 2021-02

저기서 답이 나왔네요. 관계형이 아니라면 null 이 들어가도 상관없습니다. 아마 관계형에 대한 구조를 설명해주고 싶어서 null 이 들어가면 안된다고 한듯 싶습니다.
실무에서 DB는 대부분 PK와 FK 관계를 맺게됩니다. 즉 관계를 맺는 PK는 null이 존재하면 안되는건데(데이터 정합성위반) 아마 위 설명을 뒷받침 해주고 있습니다.
null은 없어도 크게 성능상이나 기타 문제가 되지는 않으나 관계형일때는 반드시 필수조건을 만족해야 됩니다.
흠 학교다닐때 잘 가르켜준거 같네요.

배고프고가… 2021-02

술이님 정말 감사합니다. 술이님 댓글 보고 당시 디비 수업해주셨던 교수님께 속으로 감사하다는 인사를 드렸습니다.