프로젝트 6

코드 굽는 제빵사·2021년 1월 26일
0
post-thumbnail

프로젝트를 진행하기 위해 ERD 작성하기

처음엔 자바, Spring을 공부하고 무작정 머리에 들어있는대로 코딩을 했습니다.
그러다보니 이 관계가 맞나? 저 관계가 맞나?하면서 코드를 작성하고 지우기를 반복했습니다.
결국 제자리 걸음이었고 이 고민을 해결하기 위해 이호준멘토님께 조언을 구하게 되었습니다.
머릿속으로 생각만 하지말고 ERD를 작성하고 그것을 토대로 이야기하자고 하셨습니다.

그래서 주말 내내 작성하다

툴에 익숙하지 않아 헤매기도 어렵기도 했다.
ERD, UML의 끔직한 혼종을 만들어내고 말았지만 일단 가져가기로 하였습니다.
멘토님께서 entity를 통합 해야 하기도하고 삭제해야하기도 하고 이런 저런 조언을 주셨습니다.
그리고 일자, 시간을 저장하는 방법에 대해서도 알려주셔서 많은 부분을 알게 되었습니다.

아래는 1차 멘토링 이후 리뉴얼

주제 : 지하철역 근처의 알바찾기

부제 : 사장님이 직접 고용하는 가게들만 검색.

Store란 객체를 만들면서

알바몬의 기업정보 분석

기업명, 대표자, 회사주소, 사업내용으로 구성되어있다.

알바천국 기업정보 분석

회사명, 사업내용, 회사주소, 직원수, 대표자명으로 구성되어있다.
저는 알바몬, 알바천국의 정보를 바탕으로 정보를 가공하려고 합니다.
그렇기 때문에 두 회사의 공통사항인 회사명, 대표자, 회사주소, 사업내용으로
Store를 정의하기로 했다.

Store entity

나의 계획

  • 크롤링을 통해 기업정보를 등록 할 것이기 때문에 User는 Admin이다.
  • 구인 공고의 식별자로 사용하고자 한다.

문제점 그리고 해결 방안

기업의 주소 정보를 통해 가까운 지하철역을 선정한다.

  • 문제 : 기업의 주소 정보와 근무지 정보가 다를 수 있다.
  • 해결 : 기업의 주소정보와 근무지 정보가 일치하는 기업만 수집한다.

사업자 번호를 통해 기업을 식별한다.

  • 문제 : 사업자번호는 비공개이며, 기업명은 중복 될 수 있다.
  • 해결 : 기업명과 주소 일치여부로 기업을 구분한다.

Jobpost란 객체를 만들면서

알바천국 공고 상단 분석

등록일, 수정일, 근무회사명, 타이틀, 시급, 근무요일, 근무시간, 모집기간, 경력, 성별, 연령이 있다.

알바몬 공고 상단 분석

등록일, 근무회사명, 타이틀, 시급, 근무요일, 근무시간, 모집기간, 모집분야, 성별, 연령, 학력이있다.

알바 천국 근무 조건

알바몬 근무 조건

공고마다 항목유무가 꼭 필요한 항목만 추출합니다.
등록일, 타이틀, url, 시급, 근무요일, 근무시간, 경력, 성별, 연령, 학력, 마감일
또한 근무지역과 사업자의 주소지가 일치하지 않으면 수집하지 않는것으로 계획했습니다.
사장님이 직접 구인하는 가게만 수집 할 것이기 때문입니다.

JobPost entity

JobPost에서 제가 고민하고 문제가 발생 했던 것들

  • dayOfWeek
  • workhours
  • age
  • deadline

네가지 항목에서 시간을 굉장히 많이 보내게 되었습니다.

dayOfWeek

월, 화, 수, 목, 금, 토, 일 근무요일을 저장 할 수 있도록 계획된 필드입니다.

  1. 공고와 요일을 외래키로 갖는 중간 테이블을 만든다.

제가 생각하기엔 데이터베이스 관점에서의 해결이라고 생각했습니다.
하지만 멘토님께서 이렇게 만들면 하나의 공고에 여러개의 테이블이 생성되고
사용자가 사용하기 어렵다고 말씀해주셨습니다.
일단 나쁘다는 것은 알았고 좀 더 찾아보기로 했습니다.
사용자란 API를 사용하는 프론트엔드 개발자가 될수도 있고 개발자 나 자신입니다.
그리고 제가 직접 무언가 데이터를 조회하거나 데이터 조회를 바탕으로 가공 해야 한다면
많은 양의 객체를 다뤄야 해서 쉽지 않을 것이라고 결론을 내렸습니다.

  1. 문자를 저장하자.
Weekday      Letter
-------      ------

Sunday       S
Monday       M
Tuesday      T
Wednesday    W
Thursday     R
Friday       F
Saturday     U

예를 들어 월화수목금이 근무요일이라면 "MTWTF"를 데이터베이스에 할 수 있습니다.
조회를 하더라도 MTWTF로 조회하면 될 것이라고 생각했습니다.
이 방법을 찾아보면서 든 의문은 만약 문자열의 순서가 섞이면 조회가 제대로 되지 않을까란
걱정이 생겼습니다. 그리고 요일을 구분하기 위해서 2의 7승 128 가지의 문자열 조합에 대해
생각해서 준비를 해둬야 하는 것인지 이 점은 멘토님께 여쭤봐야겠습니다.

  1. 상수를 활용하자
sun=1, mon=2, tue=4, wed=8, thu=16, fri=32, sat=64. 

상수를 활용해서 요일 숫자의 합을 데이터베이스에 저장하는 방식입니다.
제가 2번 방식에서 걱정이 되었던 해결이 되지 않았던 문자열의 저장 순서가 바뀌어
문제가 생기는 경우가 없을 것이라고 생각했습니다. 그리고 128가지의 경우의 생각하지 않아도
될 것이라고 생각했습니다.

결론은 자바의 ENUM를 클레스를 활용해서 계산해서 넣는 방식을 생각했습니다.
원시타입의 상수로 사용하면 저조차도 시간이 지나면 알기 어렵기 때문입니다.

결론

@Getter
@NoArgsConstructor
public enum DayOfWeek {

    Sun(1),
    Mon(2),
    Tue(4),
    Wed(8),
    Thu(16),
    Fri(32),
    Sat(64);

    private int value;

    DayOfWeek(int value) {
        this.value = value;
    }
}

WorkHours

public class WorkHours {

    boolean     negotiation;
    LocalTime   startTime;
    LocalTime   endTime;

    public WorkHours(boolean negotiation, LocalTime startTime, LocalTime endTime) {
        this.negotiation = negotiation;
        this.startTime = startTime;
        this.endTime = endTime;
    }
}

예를 들어 08:00 ~ 17:00은 LocalTime의 변수 두개를 활용해서 표현 할 수 있다.
그런데 시간협의 이런것들은 어떻게 표시해야 할 때가 문제가 되었습니다.

저의 첫번째 해결 방법은

  1. 불리언타입을 따로 둬서 불린값을 체크해서 시간협의 기능을 표현 했습니다.
    이렇게 되면 DB에 필드가 늘어나게 되고 별도의 확인 로직이 들어가야 할 것 같습니다.
    별도의 확인 로직은 다른 방법에서도 들어가겠지만요.

  2. startTime == endTime이 같다면 시간 협의로 표현하자고 룰을 정한다.
    시간 협의를 startTime = "00:00" endTime = "00:00"과 같이
    시작시간과 끝나는 시간이 같다면 그것을 시간협의라고 인식한다.

제 생각엔 필드를 더 늘리지 않고 표현하기 위해서는 약속을 사용하는게 좋지 않을까 생각합니다.
하지만 또 읽기 편한건 필드 하나 더 박는것 같기도 한데 이것 또한 쉽지 않습니다.

ageGroup

public class AgeGroup {

    boolean     allAges;
    LocalDate   startAge;
    LocalDate   endAge;

    public AgeGroup(boolean allAges, LocalDate startAge, LocalDate endAge) {
        this.allAges = allAges;
        this.startAge = startAge;
        this.endAge = endAge;
    }
}

20세(2002년생) ~ 40세(1982년생) + 연령무관으로 검색 한다면 위의 경우처럼
startAge, endAge에 임의의 값을 지정하고 OR로 조회하면 되지 않을까 싶습니다.
하지만 코드 작성 할 때 혼란과 필드값이 늘어난다는 고민이 여기서도 생겨납니다.

deadline

LocalDateTime   deadLine;

공고 모집 마감일이 따로 없고 상시모집이라고 한다면 이것도 불리언 필드를 활용해서
상시 모집은 따로 확인 해야 할지 데드라인을 아주 멀리 2100년쯤으로 보내고 약속 된 값으로
확인 해야 할지 고민 입니다.
무언가 조건을 확인하기 위해 필드들을 늘리는 것보단 하나의 필드에서 해결 하는게 좋다고 생각하는데
어떤 선택을 해야 잘 구현 한 것인지 고민이 됩됩니다.

0개의 댓글