[24.01.05]

ERD 설계

SQL에서의 cardinality란

특정 컬럼에 나타나는 데이터의 고유값 수.

예를 들어 수백개의 row 중 성별 컬럼에는 남, 여 값밖에 없을 때 성별 column의 cardinality는 2

 

자연키(natural key) vs 대체키(surrogate key)

기본키: 테이블에서 레코드를 유일하게 식별할 수 있는 가장 적합한 후보 키

자연키: 테이블의 컬럼 중 의미를 가지고 있는 후보 키

대체키: 컬럼 가운데 유일하게 식별하기 적합한 후보 키가 존재하지 않을 때 임의의 식별번호를 부여함.

만약 자연키가 숫자로 이루어져 있다면 굳이 대체키를 쓸 이유는 없다.

데이터베이스 테이블의 대다수는 작성되는 것보다 읽히는 경우가 더 많다!!!

 

복합키의 장단점(vs 대체키)

장점

고유성 보장 - 중복값 없앨 수 있다. - 어플리케이션 단에서 중복데이터인지 검증을 한다면 성능 차이는 별로 없지만 데이터 고유성을 테이블 레벨에서 보장해주는 것.

쿼리 성능 향상 - PK 인덱스를 이용해 조회가 더 빨라진다(근데 복합키 너무 길어지면 오히려 손해)

정규화를 줄일 수 있음 - 추후 더 공부

더 많은 정보를 제공 - 여러 컬럼을 조합하면 더 상세한 정보를 키로 활용할 수 있다.

 

단점

여러 컬럼의 조합으로 이루어지기 때문에 인덱스 크기가 증가할 수 있다.

수정이 복잡해짐. - 데이터 일관성 문제의 위험

쿼리 작성이 복잡해짐 - 가독성과 유지보수 문제.

복합키에 포함된 엔티티에는 cascade 적용 불가.

우리 ERD 상에서의 유저-파티가 필요한 이유는?

파티에 있는 유저들을 조회해야하기 때문.

그렇다면 복합키 없이 대체키 두고 where party_id = 2 이렇게 해도 조회 성능의 차이가 나나?

일단 데이터가 어마무시하게 많다고 생각하면 조회성능의 차이가 난다. 왜냐면 party_id PK를 우선으로 인덱스를 만들게끔 하면 party_id = 2인 데이터들이 뭉탱이로 있을테니까

그리고 또 하나 필요한 이유는 내가 대체키를 쓰면 Long을 사용할텐데 중간테이블은 두 엔티티에 연관된 테이블이기 때문에 레코드 훨씬 많아질 가능성이 농후하다.

그러면 Long 범위를 넘어서는 대체키가 나올 수 있기때문에 복합키가 현명하다.

복합키는 cascade를 적용하는 방법이 따로 있는지(아니라면 자식 엔티티까지 하나하나 조회해서 다 없애야 한다?), 삭제여부 필드를 두는지?

disable 필드 정도만 만들어놓고. 엔티티들에만 disable 판단해 놓고 쓰는 게 낫다.

 

JpaAuditing 사용 시에 무조건 created_at과 modified_at도 같이 써줘야한다?

일대 다에서 다 쪽이 보통 중요한 데이터이다. 누가 와서 클릭을 했기 때문에 다대다 테이블에 들어가는 것이고. 실제 현업에 가면 데이터 하나하나가 마케팅 요소. 다 뽑아서 줘야한다.

 

컬럼이 하나 늘어나면 성능 이슈가 발생하지 않나요?

컬럼이 15개만 넘지 않으면 괜찮다. 일단 튜터님 같은 경우 무조건 들어가는 컬럼이 엔티티에 따라 4, 5개 무조건 있다고 생각하신다. 삭제여부, 생성시간, 수정시간.(무조건) 나머지 유저(매핑까지는 안해도), 1,2개 옵션 필수적 만약 컬럼이 15개 이상 넘어가면 일대일 테이블로 분리.

 

다단계의 계층구조 테이블이 존재할 때 조회를 어떻게?

댓글이 존재하는 보드를 댓글-카드-컬럼-보드 순으로 올라가서 판단하기 보다는(서비스단)

요청에 보드아이디를 넣어준다.

시큐리티 컨텍스트에 내가 만든 보드들을 넣어놓고 검증

argument resolver 컨트롤러 단의 어노테이션

예를 들어 보드 1번이 와슨데

1번 보드가 없는 경우 - > 보드레포지토리에서 해결

보드 2번이 왔고 댓글 3번이 왔는데 (보드 2번에 댓글 3번이 존재하는지 확인)

서비스의 성격에 따라 다르다

퍼블릭 서비스- 권한 따로 필요없는. 룰에 따라서 혼용하여 사용하면 좋다.

 

 

느낀 점

진짜 팀장급 실력 아닌데 리더를 맡게 되어서 힘들지만 오히려 기회다 화이팅하자.