Seo-yeong-Chae
commented
12 months ago ★ 정규화를 고려해서 db 테이블 컬럼 재배치(구조) 고민 + 근거
1>> user 테이블이 존재하는데, 같은 정보를 저장하고 있는 account 테이블이 불필요해보임. 따라서 account 테이블을 삭제하고, user 테이블에 누락된 image_url, nickname 컬럼만 user 테이블로 넘겨주면 효율적일 것.
2>> authentication_password 테이블의 경우, 비밀번호 인증을 위한 테이블이기 때문에 유저 id와 유저 이름, 비밀번호 컬럼만 남겨두고, 생성일자와 갱신일자는 인증시 사용하지 않는 컬럼들이기 때문에 제거하는 것이 테이블 조회를 효율적으로 하는데에 도움이 될 것
3>> authentication_social 테이블의 경우, 존재 자체가 모호하기 때문에 db에서 삭제하는 것이 나아보임.
4>> account bank_account 테이블에서, primary key인 맨앞의 인덱스 id 컬럼은 불필요하므로 삭제하는 것이 나은 것 같음. 또한 고유한 값인 account_number가 있는데, 굳이 account_id를 만들 필요가 없어보임. account_number를 bank_account의 primary_key로 쓰고, account_id 대신 account_number를 user테이블에 외래키로 넘겨주는 것이 나음. account_id 컬럼은 삭제하는 것이 나아보임.
5>> bank_account_transaction 테이블의 경우, 언제 거래가 이루어졌는지를 저장하고 있는 transaction_at 컬럼이 있기 때문에 생성일자, 갱신일자 컬럼은 불필요하므로 삭제, 은행계좌 id, 수금 계좌 id, 송금 계좌 id 컬럼 또한 삭제 후 송금 계좌 번호, 예금 계좌 번호를 bank_account로부터 각각 외래키로 넘겨받도록 재설계하여야 할 것 같음.
그리고 status 컬럼은 휴면 계정 관리시, 계좌 사용을 정지시키는 컬럼으로 사용될 수 있을 것 같지만, code 컬럼은 계좌 거래 내역을 관리하는 것과 관련이 없어보이므로 삭제하여야 할 것으로 보임.]
6>> bank_branch 테이블의 경우, branch_id 컬럼을 bank_account 테이블에 외래키로 넘겨주어야 할 것으로 보임.
7>> comment 테이블의 경우, comment_seq 컬럼의 용도가 모호하므로 삭제하는 것이 나아보임. 또한 comment 컬럼의 외래키로 inquiry_id가 존재하기 때문에 user_id까지 외래키로 저장하는 것은 불필요함. 따라서 user_id는 외래키에서 제외하고 comment 테이블에서 삭제하는 것이 나아보임.
8>> user 테이블의 경우, authentication_type 컬럼의 의미가 모호하므로 api 팀과 토의 후 불필요하다면 삭제하는 것이 나아보임. 또한 deleted_at 컬럼의 경우에는 이미 삭제한 계정의 데이터를 남겨둘 이유가 없으므로 이 컬럼 역시 삭제하는 것이 타당해보임.
<타임뱅크의 테이블> account : 유저의 계정 정보를 저장한 테이블로, 계정 id, 생성일자, 갱신일자, 삭제일자, 이름, 프로필 이미지의 url, type(?) 컬럼이 있음. (user 테이블과 겹치는 컬럼이 많아 이 테이블을 삭제하고 user에 누락된 컬럼들만 user로 넘겨주는 것이 나아보임.) authentication_password : 비밀번호 인증을 위한 테이블로, 유저 id, 생성일자(테이블 조회의 효율성을 위해 제거), 갱신일자(테이블 조회의 효율성을 위해 제거), 비밀번호, 유저이름 컬럼이 있음. authentication_social : (역할이 모호한 테이블이므로 삭제), 유저 id, 생성일자, 갱신일자, 플랫폼 유형(?), 플랫폼 유저 id(?) 컬럼이 정의되어 있음.
bank_account : 은행 계좌 번호 테이블로, 인덱스_id(불필요하므로 삭제하고, 계좌번호를 primary key로 지정), 생성일자, 갱신일자, 계좌번호, 잔액, 삭제일자, 예금주, 계좌 비밀번호, 계좌 id(계좌번호라는 unique한 값이 있으므로 삭제 가능), 지점 id 컬럼이 정의되어 있음. bank_account_transaction : 은행 계좌의 거래 내역을 저장하는 테이블로, 인덱스 id(?), 생성일자(transaction_at 컬럼이 따로 있기 때문에 삭제), 갱신일자(transaction_at 컬럼이 따로 있기 때문에 삭제), 거래금액, 잔액 snapshot(?), 은행 계좌 id(삭제), 코드(불필요해서 삭제), 상태(휴면 계정 관리시, 계좌 사용을 정지시키는 컬럼으로 사용될 수 있으므로 보류), 거래일자, 수금 은행 계좌 id(삭제후 수금 계좌 번호 컬럼 추가), 송금 은행 계좌 id(삭제 후 송금 계좌 번호 추가) 컬럼이 정의되어있음.
bank_branch : 은행 지점의 정보를 저장하는 테이블로, 은행 지점 id, 생성일자, 갱신일자, 은행 이름 컬럼이 있음. (지점 id 컬럼의 경우, bank _account 테이블에 외래키로 넘겨주어야 할 것으로 보임)
comment : 유저들의 문의에 대한 은행의 답변을 저장하는 테이블로 추정됨(?), 인덱스 id(?), comment_seq(용도가 모호하므로 삭제), 내용, 문의 id, 유저 id(문의 id 컬럼이라는 외래키가 따로 있기 때문에 불필요하므로 삭제) 컬럼이 존재함. failed_attempts : 로그인 시도 횟수를 기록하는 테이블로 추정됨.(?) 로그인을 시도한 장치의 ip 주소(?), 시도 횟수 컬럼이 존재함.
inquiry : 유저들의 문의사항을 기록하는 테이블로, 문의 id, 내용, 문의일자, 응답상태, 제목, 유저 id 컬럼이 있음.
user : 유저의 정보를 저장하는 테이블로, 유저 id, 생성일자, 갱신일자, 인증 유형(api 팀과 토의 후 불필요하다면 삭제), 생년월일, 삭제일자(불필요하므로 삭제), 성별, 최근 로그인 일자, 이름, 휴대폰 번호, 계좌 id(삭제 후 계좌번호 컬럼으로 대체) 컬럼이 정의되어 있음.
<이슈 사항> 1) 테이블 별로 의미가 모호한 컬럼들이 있음. (?)를 붙여놓은 컬럼들의 의미를 확인하고 필요한 컬럼인지를 따져볼 필요가 있어보임. 2) 특정 테이블들은 존재의 의미가 모호함. authentication_social, comment, failed_attempts 테이블이 이에 해당함. 이것들 역시 의미를 확인하고 필요한 테이블인지, 아니면 다른 테이블에 포함시킬 수 있는지등을 검토해보려함.