[일반] 컬럼 타입 리스트 vs 행 개수 늘리기 님들 의견은 어떰

[익명(223.38)]

재밋는얘기하자

구독자는 여러개의 채널을 구독할 수 있다

니네가 구독 중인 채널의 정보를 쌓는 테이블을 설계한다면 어떻게 할래?

1. 구독자 - 구독정보(List<String>) 1:1 (구독하는 만큼 리스트에 추가)

2. 구독자 - 구독정보(String) 1:N (구독하는만큼 행늘어남)

선택 이유도 궁금함

구독자 규모는 임의로 지정 가넝하고 규모 기준으로 선택 방식이 달라진다면 왜인지도 적어주면 고맙겠음

[밀우(ggbadza2)]

전자는 rdb방식이고 후자는 nosql(json) 방식에 가까운데 rdb에 단순 문자열로 저장하는거면 파싱해야하고 락경합등 데이터쌓일수록 문제니깐 전자처럼 구현할거고 mongodb면 후자처럼 할듯

[익명(alter1257)]

반대아님? 전자가 몽고 뒤가 rdb

[익명(223.38)]

아 내가 조건을 안 걸었네 글 수정해둘게 미안하다 나도 너랑 똑같이 할 거 같은데 혹시 RDB인 경우에 후자처럼 했을 때도 이점이 있을지가 궁굼했슴

[익명(223.38)]

@글쓴 백갤러(223.38) 나도 반대로 적엇네 ㅅㅂ

[밀우(ggbadza2)]

@ㅇㅇ 전자가 정규화 빡세게한거니 rdb 기준 관계 하나당 행1개 추가하는거잖아. 조인최적화 ㅇㅇ

[익명(223.38)]

@밀우 사실 RDB인데 후자로 하자는 걸로 20분인가 토론하는 상황을 겪어서 내 능지가 박살난건지 싶어서 질문 올려봤어 내 대가리가 쪼개진건 아니엇구나 다행이다 고맙다...

[익명(223.38)]

@글쓴 백갤러(223.38) 또 반대로 적엇네 Rdb인데 리스트 스트링으로 하자는 걸로 20분을 토론함...

[밀우(ggbadza2)]

@글쓴 백갤러(223.38) 이점이야 구독정보만 끌고올 일이 없고, 특정 구독자가 가진 모든 구독정보만 끌고오면서 특정 구독에대한 구독자 데이터를 조회할 일이 없을땐 성능적으로 좋겠지. 근데 문자열로 저장된 구독정보를 다시 파싱해서 리스트로 만들어주고 그거 기반으로 실제 구독테이블에서 조인해야하는 불편함도 있을거라. 성능이 암만좋아진대도 개인당 구독 몇백개 이상 될거 아니면 크게 차이가 없어서 후자로 할 이유가 거의 없긴함.

[밀우(ggbadza2)]

@밀우 아 후자가 관계 하나당 행이 늘어나는건가?

[익명(223.38)]

@밀우 ㅇㅇㅇ 너가 적어준 내용 대충 전후자 반대로 해서 이해했어 반대로 맞지??

[익명(alter1257)]

2. 구독자 - 구독정보(String) 1:N (구독하는만큼 행늘어남) "A 채널을 구독하는 사람들" 이런식의 데이터가 필요할 수 있음

[익명(223.38)]

오 이것도 고려하는게 맞겠네 의견 고마워

[익명(223.38)]

글 수정이 안 되네 RDB 기준으로 생각해줘

[익명(alter1257)]

RDB 기준에서 전자가 사용 가능한 시점은 해당 데이터가 완전히 종속적이여야함. 근데 구독정보는 구독자와 채널 둘 사이의 연관관계기때문에 전자로하면 안됨

[익명(223.38)]

@ㅇㅇ 연관관계까지 ㄷㄷ 디비 설계원칙 빡세게 했구나

[딘퐁(film1341)]

RDB면 채널 - 구독자 관계를 정의하세요. 전자요 - dc App

[딘퐁(film1341)]

아니 후지요 - dc App

[딘퐁(film1341)]

후요 - dc App

[익명(alter1257)]

이사람도 전자랑 후자랑 헷갈려하네 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ왜 여기 죄다 전자랑 후자랑 자꾸 바꿔서 적냐

[익명(223.38)]

@딘퐁 미안하다 저렇게 적은 내 잘못이다 나조차도 전자인지 후자인지 헷갈리고 있으니 의견 고마워!!!

[딘퐁(film1341)]

@ㅇㅇ 구독자 순위로 정렬 등등 유연하게 기능 지원 가능 칼럼에 리스트박으면 구현이 ㅈㄴ번거로워짐 - dc App

[익명(223.38)]

@딘퐁 고마우 좀 전에 알디비인데 리스트 스트링으로 하자는 얘기 듣고 설득하다가 걍 포기하고 내가 잘못 생각하는건가 싶엇다...