🗃️ [STMT-220] 테이블 study_domain 외래키 제약조건 변경 및 각 필드 데이터 크기 증대

[05AM]

💁 해결 하려는 문제를 적어주세요

• 테이블 study_domain ddl 제약조건 설정 실수로 flyway의 실행에 오류가 있었습니다.

🤔 어떤 방식으로 해결했는지 적어주세요

[이전 코드]

`study_field_id` BIGINT NOT NULL COMMENT '스터디 분야 ID',

    CONSTRAINT fk_study_field FOREIGN KEY (study_field_id)
        REFERENCES study_field (id)
        ON DELETE SET NULL ON UPDATE CASCADE

• 이전 코드에서 외래키 제약 조건을 삭제 시 null로 설정하게 해두었는데 외래키 필드가 not null로 설정되어 있어 문제가 발생했습니다.
• 해당 부분을 nullable로 선언하였습니다.

🙋 중점적으로 리뷰 했으면 하는 부분이 있다면 적어주세요

• 이전 코드는 요구사항에 딱 맞게 데이터 크기를 설정했는데, 변경하는 김에 크기를 조금씩 증가시켰습니다.
• 일반적으로 데이터 크기를 조금 여유있게 잡는 것은 데이터 무결성을 위해서 또는 미래의 요구사항 변경 시 데이터 크기 변경이 성능에 영향을 주기 때문이라고 합니다.
• 하지만 조금 고민이 되는게 만약에 (저의 잘못이겠지만) 예외처리가 잘못되어 스터디 인원에 50명 이상이 들어간다던가, 소개글, 규칙 등에 100자 이상이 들어갈 수 있는 가능성이 생기는 것이 걱정이 됩니다.
• DB로부터 에러가 발생하여 서버 에러 (Internal Exception)이 응답되는 것보다는 낫다고 생각하지만 이에 대해서 어떻게 생각하시는지 궁금합니다!

[zxcv9203]

• 이전 코드는 요구사항에 딱 맞게 데이터 크기를 설정했는데, 변경하는 김에 크기를 조금씩 증가시켰습니다.
• 일반적으로 데이터 크기를 조금 여유있게 잡는 것은 데이터 무결성을 위해서 또는 미래의 요구사항 변경 시 데이터 크기 변경이 성능에 영향을 주기 때문이라고 합니다.
• 하지만 조금 고민이 되는게 만약에 (저의 잘못이겠지만) 예외처리가 잘못되어 스터디 인원에 50명 이상이 들어간다던가, 소개글, 규칙 등에 100자 이상이 들어갈 수 있는 가능성이 생기는 것이 걱정이 됩니다.
• DB로부터 에러가 발생하여 서버 에러 (Internal Exception)이 응답되는 것보다는 낫다고 생각하지만 이에 대해서 어떻게 생각하시는지 궁금합니다!

비즈니스적으로 얼마나 문제를 야기할 수 있는지를 기준으로 보면 좋을 것 같습니다.

소개글, 규칙 같은 것은 100자 이상 넘어올때 영속성 계층까지 넘어오게 작성된 것 자체가 이전 객체가 역할을 못했다는 것을 의미하기도 하고 사실 100자가 넘는다고 해서 시스템에 치명적인 장애를 야기시키는 부분도 아니라고 생각합니다.

지금보니까 인원수의 경우 별도의 칼럼을 두면 동시성 문제가 발생하기 쉬울 것 같아 카운트 쿼리로 두는 것도 좋을 것 같습니다 🤔

[05AM]

지금보니까 인원수의 경우 별도의 칼럼을 두면 동시성 문제가 발생하기 쉬울 것 같아 카운트 쿼리로 두는 것도 좋을 것 같습니다 🤔

오 카운트 쿼리로 하는것은 생각을 못해봤는데 좋은 것 같습니다! 추후 관련 내용 습득하여 반영해보겠습니다!