Inflearn Community Q&A
asked
이력 관리 테이블 설계에 대해 질문드립니다
Written on
·
4.8K
0
안녕하세요 강사님 강의 정말 잘 듣고 있습니다
제가 고민을 해봐도 해결되지 않는 내용이 있어서 질문을 드립니다
제가 유저 개인정보 변경 이력 테이블을 만들려고 하는데요
유저 개인정보는 관리자가 관리자 페이지를 통해서 변경할 수도 있고
사용자가 직접 마이 페이지를 통해 변경할 수도 있습니다
예를 들어 바뀔 수 있는 항목 3개라 치고 A, B, C라고 칭한다면
(항목은 이메일, 담당자 이름, 근무지, 근무 상태 같은 것들입니다)
변경 전 before A, before B, before C
변경 후 after A, after B, after C
변경일자 xxxx.xx.xx
개인정보가 변경 될 때마다 데이터가 쌓여, 변경일자 내림차순으로 화면에 보여지는 방식입니다
A만 변경했다고 하더라도 A, B, C는 전부 표기되어야 합니다
1. 이력 관리는 1개의 테이블에 같이 저장하면서
대신 컬럼 하나 추가해서 개인정보를 관리자가 변경했으면 1, 사용자가 변경했으면 2 이런 식으로 플래그를 주려고 합니다
이러한 방식으로 설계하는 게 맞다고 생각은 되는데
혹시 요구사항에 따라서
2개의 테이블(관리자가 이력 관리한 테이블, 사용자가 이력 관리한 테이블)로 분리해서 각각 저장하는 방식으로
설계하는 경우도 있을지 궁금합니다
2. 만약에 화면에 보여지는 그대로 before, after, 변경일자 테이블 컬럼을 생성한다면
설계는 쉽겠지만 추후 변경할 수 있는 개인정보 항목이 더 늘어날 걸 생각하면 확장성이 좋지 못하고
또 1개 항목만 바꾸고 저장했을 때도 전부 다 DB에 저장하는 거는 더미 데이터가 많이 쌓여서 좋지 못할 것 같습니다
이력 관리 테이블 설계에 대해서 혹시 조언해주실 수 있는 점이 있으실까요?
Answer 2
0
지금 질문은 제가 만들고 있는 데이터베이스 중급과정에서 자세히 다룰 계획입니다. 분명한것은 그렇게 해도 테이블간 관계가 유지된다면 괜찮습니다. 다만 테이블이라는 것은 합쳤을때 괴로운 일이 많이 일어나고 나눌수록 편안해집니다
혹시 테이블을 나누면 활용할때 조인등 힘든게 있을것 같지만 전혀그렇지 않습니다.
그리고 테이블을 나누는 중요한 이유는 객체지향 언어로 각 테이블을 모델링할 수 있기 때문입니다. 그럼...
0
이력테이블 History(dummy_key, a,b,c,RegistedDate, UserId) or
이력테이블 History(a,b,c, seq, RegistedDate, UserId)
굵은 컬럼이 PK, dummy_key는 자동증분,
seq는 a,b,c에 대해서 1씩 증분
(저는 개인적으로 a,b,c,seq가 개발은 힘들지만 성능면에서 추천합니다)
위와 같이 두개의 방법이 있겠죠. UserId를 써야지 1,0을 사용하는 방법은 의미를 제한시키는 단점이 있고 왜 그렇게 해야 하는지 모르겠어요.
이력관리가 매우 중요한 사안이라면 트랜잭션을 걸어서 사용해야 하고, 안 그러면 레코드 UPDATE, 이력관리 테이블에 NSERT 이렇게 두 개 명령을 실행하면 되겠습니다.
강사님 답변 정말 감사드립니다
혹시 다양한 이력 정보를 한 테이블에서 관리해도 될까요?
현재 USER_HISTORY 라는 테이블이 있고 관리 타입 컬럼을
1 유저 권한 변경(관리자 계정만 가능하며 변경 시 이력 저장)
2 탈퇴 처리(관리자가 탈퇴 처리했을 경우에만 이력 저장)
3 회원 정보 수정(기존에 질문드린 내용)
로 주고 있는데요
만약에 권한 변경이 A 항목만 쓰고 탈퇴 처리는 B 항목만 쓰고 회원 정보 수정이 C, D, E, F, G 항목만 쓴다면
이걸 USER_HISTORY 테이블에 다 이어서 컬럼을 생성하면 너무 공간 낭비가 아닐까 싶기도 한데
그렇다고 테이블을 분리하는 게 맞는지도 모르겠습니다 ㅠㅠ
예를 들어 관리자가 유저 권한 변경을 하고 저장을 했다면
row가 insert 될 때 관리 타입은 1로 들어가고 A 컬럼에는 변경 데이터가 들어가 있겠지만
연관 없는 B 컬럼부터는 변경 내역이 없으니 null이 들어갈 테니까요
이 부분에 대해 어떻게 생각하실까요?
그리고 처음 질문드린 내용처럼 변경 전후를 전부 보여줘야 하는데요
변경 전 A, 변경 전 B, 변경 전 C.... 변경 후 A, 변경 후 B, 변경 후 C... 변경일자 컬럼을
다 생성한 다음에 한 row에 상태값을 통째로 저장하는 방식은 뭔가 아니라는 생각이 드는데
이 부분에 대해서도 조언을 주실 수 있는 점 있으실까요?
감사합니다
강사님 답변 감사드립니다
데이터베이스 중급과정도 올라오면 나중에 수강하도록 하겠습니다~