C조 [DB 변경] 쪽지 테이블(t_post)

[choong]

안녕하세요 ^^
아래 컬럼 t_post 테에블에 추가 부탁 드립니다.
USER_ID 는 기존 테이블과 동일하게 주시면 됩니다.

POST_ID varchar(40) not null pk 쪽지 마스터 ID
USER_ID
POST_TYPE varchar(1) not null 쪽지 종류 보낸 쪽지 : S, 받은 쪽지 :R
POST_STATUS varchar(1) not null 쪽지 상태 읽음 : Y, 안읽음 N

PK : POST_ID, USER_ID , POST_SEQ

[1angerhans]

POST_ID 가 varchar 인 이유는 무엇인가요?
varchar를 pk 로 잡으면 성능상 저하가 심할듯 싶은데요.
그리고 USER_ID는 SENDER_ID, RECIPIENT_ID, USER_ID 이렇게 3개가 들어간다는 말씀이신가요?

[choong]

별다른 이유는 없습니다. mysql에 시퀀스가 없기 때문에 날짜(20140126)+특정값(0000001)을 넣기 위해서 varchar로 넣었습니다. 성능상에 이슈가 발생하면 int로 변경 하겠습니다.
그리고 SENDER_ID, RECIPIENT_ID 컬럼은 삭제 하고 TARGET_ID로 하나로 사용하면 될것 같습니다.

혹시나 문제가 되는 부분이 있으면 말씀 해주세요.

의견 감사합니다. ^^

[1angerhans]

아 그럼 보낸쪽에서는 누구한테 보냈는지에 대한 참조가 없고,
받는쪽에선 누가 보냈는지에 대한 참조가 없네요.

음. 아무래도 매핑 테이블을 이용하는게 좋을 듯 싶습니다.

t_post 테이블에서는 보낸사람에 대한 USER_ID 만 가지고 있구요.
한개만 저장을 합니다.

t_postmapping 테이블을 만들어서

POST_ID, POST_SEQ, USER_ID, POST_TYPE, POST_STATUS

를 각각 사용자에 대하여 매핑하는것은 어떨까요?

t_post 와 t_postmapping 는 POST_ID, POST_SEQ 로 매핑 하구요.

POST_ID 는 마스터 시퀀스로 같은 쓰레드는 중복이구요.
POST_SEQ는 유니크로 쓰레드 상에서 중복되지 않습니다. auto_increment 로 해도 되겠네요.

삭제할때는 쪽지를 지우는것이 아닌 t_postmapping 만 지워 참조를 지우는 방식으로 하면,
한쪽에서 지워도 한쪽에선 참조가 가능하게 될듯 싶습니다.

어떠신가요?

[yjc0703]

쪽지 1건당 2row 가 insert 되는 구조로 보입니다.
이유에 대해서 간략하게 설명해주시면 병태씨가 이해하기 좋을 것 같네요 ^^
2014. 1. 27. 오후 6:29에 "정병태" notifications@github.com님이 작성:

아 그럼 보낸쪽에서는 누구한테 보냈는지에 대한 참조가 없고,
받는쪽에선 누가 보냈는지에 대한 참조가 없네요.

음. 아무래도 매핑 테이블을 이용하는게 좋을 듯 싶습니다.

t_post 테이블에서는 보낸사람에 대한 USER_ID 만 가지고 있구요.
한개만 저장을 합니다.

t_postmapping 테이블을 만들어서

POST_ID, POST_SEQ, USER_ID, POST_TYPE, POST_STATUS

를 각각 사용자에 대하여 매핑하는것은 어떨까요?

t_post 와 t_postmapping 는 POST_ID, POST_SEQ 로 매핑 하구요.

POST_ID 는 마스터 시퀀스로 같은 쓰레드는 중복이구요.
POST_SEQ는 유니크로 쓰레드 상에서 중복되지 않습니다. auto_increment 로 해도 되겠네요.

어떠신가요?

Reply to this email directly or view it on GitHubhttps://github.com//issues/101#issuecomment-33352162
.

[yjc0703]

메일 답장으로 보내면 코멘트가 지저분하네요^^
답변달고나서 생각해보니 삭제문제때문에 그러신게 아닌가 생각이 듭니다.
받은쪽에서는 삭제해도 보낸쪽에서는 남아있도록...맞나요? ㅎㅎ

[1angerhans]

네네 맞습니다. :)
그래서 @choong 님게서 말씀하신 구조에서는 보낸사람과, 받는사람 이 각각의 row에 나뉘어 져 있어서 참조하려면 2개의 row를 다 가져와야 될 듯 싶어서요.
그러면 실제 데이터를 보여줄때 각 row를 또 합쳐서 보여줘야 될꺼 같아서 그렇습니다.
아무래도 프로그램 로직이 복잡해질 듯 싶어서요.

흠...제가 뭔가 빠뜨리고 생각한건 아니죠? ㅎㅂㅎ.....

[yjc0703]

수신자의 수신여부를 송신자에게 보여주려면 참조가 있어야할텐데 그게 없군요..
매핑을 두고 실데이터 삭제하면 어차피 참조가 깨지니 삭제플래그를 두는게 맞는것같고 그럴꺼면 다시 역정규화로 가는게 맞는것도 같네요...

[choong]

네 쪽지 1건당 두개의 row가 인서트 되는 구조입니다.

보낸사람이든 받는 사람이든 둘다 인서트되고

User_id 에는 각각의 사용자의 아이디가 타겟아디에는 보낸사람과 받는 사람의

아디가 들어갑니다 받은쪽지인지 보낸 쪽지인지 post type컬럼으로 구분할 예정입니다.

그러면 테이블 하나만 있으면 될것 같습니다.

테이블 구성은

POST_ID, POST_SEQ, USER_ID, POST_TYPE,TARGET_ID, POST_STATUS

내용 보낸날짜 받은날짜만 있으면 될것 같은데 제가 놓친부분이 있나요..

한쪽에서 물리적으로 삭제해도 다른쪽에서도 영향은 없을것 같습니다

폰으로 적는거라 적기 너무 힘드네요ㅎㅎ

이해 안되는 부분이 있으면 말씀해주세요

[yjc0703]

제가 잘못이해했네요 폰으로 보다보니 꼼꼼하게 보지를 못했습니다.
그치만 말씀하신대로도 문제는 보이네요
저도 폰이라 힘들어서 ㅠ 병태씨가 정리해주실듯 ㅎㅎ

[1angerhans]

제가 어제 뭔가 장황하게 썼는데 안올라갔네요 ;;;
일단 테이블 수정은 완료됬습니다. 확인해보시고 다른 사항 있으시면 또 말씀해주세요.

@dbjongjin 님 버전관리 부탁드립니당~

[dbjongjin]

이 전글의 이슈 부분은 버전 업데이트를 완성했으나, 이쪽 부분은 이해가 잘 되지 않습니다.
컬럼 추가 시 코멘트를 달아주셨으면 좋겠습니다.

이 부분에 대해서 정리해서 전달 부탁드립니다.
테이블 정의서만으로는 컬럼의 코멘트만 보고 이해 하지 못하는 부분이 많습니다.
*(코드화로 y/n , 1/2/3, 부모id, 자식id 등)

이 부분은 차후 코드 리뷰 자리에서 각 맞으신 테이블의 컬럼 설명을 다시 종합적으로 해주시기 바랍니다.
차후 매뉴얼 작성에 참고하고 싶습니다.

이 이슈에 대해 결론적인 설명 부탁드립니다.

[choong]

쪽지 테이블 수정 요청 드립니다.
*pk : POST_ID, USER_ID, POST_SEQ

*POST_ID 데이터 타입 unsigned BIGINT

• post_id 는 auto_increment를 사용하지 않고 유니크한 값 (20자리 숫자)을 만들어서 사용할 생각입니다.(nano time(14) + random(6)). 혹시 자릿수가 커지면 속도의 영향이 발생하나요?

*POST_SEQ auto_increment 속성 추가 부탁드립니다.
혹시 궁금한점이 있으면 말씀 해주세요

[1angerhans]

작업을 해보니 auto_increment 는 최순위 uniq key에만 할당이 되는군요.
즉, post_seq 를 auto_increment 로 설정할 경우 post_id 와 user_id를 키로 잡는 건 무의미 하게됩니다.
그래서 post_id를 auto_increment 로 하고 post_seq를 post_group 나 post_thread 으로 바꾸는 것이 어떨까 싶네요.