null이나 blank 필드 어떻게 처리하세요? 제 생각도 첨부합니다. 0 2 197

by 보보 [DB 모델링/설계] [2020.02.13 13:19:03]


정석적으로 하려면 빈 필드나 null인 필드가 자꾸 늘어나면 불필요한 필드가 자꾸 쌓여나가는거니 따로

FK로 빼서 테이블 하나로 관리하는게 맞을듯 한데요.

 

예를들면 회원가입 시 선택 입력 되는 것들

본 글쓰기 에디터에서도 분류 / 태그 등은 다 선택적으로 입력하게 되어있고,

특정 조건에 따라 발현되는 인풋들까지 모두 고려해서 다 일일히 테이블로 빼내면 테이블이

서비스 규모에 따라 수십 수백개로 늘어날 것 같은데, null이 될 가능성이 아주 높은 필드들은 빼주는 것이 좋고

그렇지 않은 것들은 테이블 안에 같이 두는 것이 낫겠죠?

물론 어느 테이블에 넣을지 결정하는 건 신중하게 해야겠지만요.

 

여러분은 어떻게 하고 계신지 궁금합니다.

Stackoverflow에도 이견이 많더라구요.

뭐 nullable field를 relation으로 따로 빼는 건 무결성을 위해서 해야한다는 입장과

그건 학교에서나 이론으로 배우는거지 현업에서는 그렇게 하려면 thousand of tables가 된다고 

적당히 합칠 것들은 합쳐라라는 의견으로 나뉘더라구요.

그리고 thumbs up 수를 보면 후자가 의견이 더 많은 듯 하구요.

 

혼란스럽기도 해서 가장 쉬운 데이터베이스 설계 책을 이틀에 걸쳐서 열심히 봤습니다.

거기선 되도록 무결성을 지켜주고 nullable이나 blank가 어쩔 수 없이 사용해야할 때만 사용하라라고 되어있는데

그렇지 않은 경우는 선택적으로 입력되는 데이터들은 본 에디터만해도

태그 / 파일수정 / 파일추가 필드를 각각 테이블로 개별적으로 다 뺄 순 없잖아요..ㅎㅎㅎ;;

한데 묶어두면 어떤건 입력되어있고 어떤건 분명 비어있을텐데 말이죠.ㅎ

by 보보 [2020.02.13 13:28:10]

만약에 사용자 입력이 아예 없는 경우는 null로 두고 빈 값으로 두는 경우는 default 값을 설정해서 구분해주는 것이 좋겠죠?

(이것도 제 의견입니다.)


by 보보 [2020.02.13 16:04:02]

입력이 없으면 NULL로 두고 빈값은 빈값 그대로 두고,

변경중에 null이 됐는데 NULL로 표기가 힘든상황이면 N/A 나 Not Applicable로 표기하라고 합니다.

그리고 널은 따로 테이블로 뺄 필요는 없고 목적에 맞게끔 잘 사용해주면 됩니다.

예를들면 값이 누락되는 경우나 알려지지 않은 값이 들어올때는 Null로 처리하면되요.

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입