[DB] DB 모델링 - 소셜 로그인기능

 소셜 로그인 기능이 구현된 서비스에서는 db 설계를 어떻게 해야할지 고민해봤다

 

고민해봐야 할 점들은 다음과 같았다.

 

1. 소셜로그인 계정과 로컬 계정은 db에 저장할때 공통된 데이터도있고, 다른 데이터도 있다. 이를 어떻게 구분해서 관리할 것인가?

ㄴ테이블 분리 vs 테이블 통합

 

2. 식별관계 vs 비식별 관계

 

3. soft delete

 

 

결과)

 

 

 

 

 

1. 소셜계정, 로컬계정, 사용자에 대한 테이블을 모두 분리하여 db설계를 했다.

 

테이블을 왜 모두 통합하지않고 분리했는가?)

 

->  소셜로그인 기능 도입으로, 계정의 종류에 따라 필요한 데이터 종류들이 많이 달라지게되었다.

 

이렇게되면, 계정마다 필요하지않은 데이터에 대한 값들은 null로 저장되어 테이블내에 null 값이 많아지게된다.

 

적어도 한 개의 행에서 null값이 1번이상은 발생한다.

 

테이블에 null 값이 저장되는 경우를 최소한으로 줄이기 위해 이렇게 하였다.

 

 

그리고 테이블을 통합할경우, 특정 컬럼에 의해 특정컬럼의 값이 영향을 받게된다.

 

예시) 모든 테이블이 통합되었을 경우)

 

provider (타사 소셜서비스)에 kakao가 들어가면 kakao_key 에는 특정값이 들어가며, id, pw는 null값이 들어간다

 

local이 들어가면 kakao_key는 null값이, id,pw에는 특정값이 들어간다.

 

그래서 테이블을 분리하여 관리하기로 하였음.

 

 

 

 

테이블 용도)

 

-user 테이블 : 여기서 user테이블은 모든 계정들에게서 필수적이고 공통되는 데이터들을 저장하기 위한 목적으로 생성되

 

었다. 소셜이든 로컬이든 회원가입된 모든 계정 데이터는 기본적으로 여기에 저장된다.

 

추후에 사용자에대한 이름, 연락처, 성별등에 대한 데이터가 추가된다면 이 테이블에 추가된다

 

 

-account_local 테이블 : 자사 서비스로 회원가입한 계정은 id, pw를 우리 db에 저장해야한다

 

 

-account_kakao 테이블 : 소셜로 회원가입한 계정은 id,pw가 별도로 존재하지않는다. 로그인 기능 자체를 그 소셜서비스에

 

서 대신해주기 때문이다. 다만, 계정마다 키를 부여받기에 이를 저장해줄 공간이 필요하다. 

 

 

 

 

 

2. 사용자-카카오계정, 사용자-로컬계정을 각각 식별관계(외래키를 기본키)로 지정해주었다.

 

 

사용자테이블은 로컬계정테이블과 부모자식관계이다(사용자테이블에 값이 있을때만 로컬계정테이블에 값이 들어갈 수

 

있음)

 

그리고 사용자테이블(부모)에 값이 있을때도, 로컬계정테이블(자식)에는 값이 단 하나만 들어갈 수 있고, 2개이상은 안됨.

 

그렇기에 로컬 계정테이블에서 외래키인 user_idx가 중복될일이 없다. 그래서 user_idx를 외래키이자 기본키로 지정하여 

 

식별관계로 형성하였다.

 

 

실제로는 식별관계여도 테이블간 유연한관계를 위해 비식별관계로만 만드는 경우가 많은 것으로 알고있다.

 

개발자에게 다양한 요청(특정 테이블에 데이터들을 미리 넣어놓고 나중에 연결하고싶다 등.) 을 수행하기위해서는

 

비식별관계로 만드는 것이 좋다고 들었다.

 

하지만 현재 프로젝트에서는 그런 예외적사항은 없다고 가정하고, 현 프로젝트에 fit하게 맞추기위해서 식별관계로 설정하

 

였다

 

 

 

 

3. deleted_at으로 삭제여부와 삭제시간을 모두 표현하기 위해서 null값이 허용되도록 만들었음. soft delete

 

deleted_at에 값이 들어있지않으면 삭제x, 들어있으면 삭제o, 데이터타입을 timestamp로지정하여, 삭제시간도 알 수 있다.