본문 바로가기
Develop/Etc

발주 회차 정보 추가

by bellsilver7 2022. 3. 30.
728x90

  하루에 몇 번에 걸쳐 발주라는 처리가 진행되고 있다. 업체에서 이 데이터를 회차별로 조회할 수 있도록 하기 위한 기능 추가 요청이 들어왔고 이 회차가 업체별로 1부터 카운팅되야 한다고 했을 때 아래와 같이 방법에 대해 정리해보았다. 테이블의 경우 최적화는 이후에 생각해보기로 하고 먼저 필요한 항목들을 적어보았다.

 

현재 발주 테이블에서 사용하지 않는 datetime 필드를 사용할 경우

1) 작업: 발주시 해당 필드를 update 항목에 추가
2) 장점: 작업 분량이 적다.

3) 단점: 회차 조회시 datetime 타입의 필드를 group by 해야하고 하루를 넘어간 기간의 회차 조회시 rank 를 매겨야 함.

 

신규 테이블을 생성할 경우

# N:1 관계 테이블 

create table `일일발주회차`
(
    `발주일련번호` bigint   not null auto_increment,
    `발주회차`   tinyint  not null default 1,
    `발주일시`   datetime not null,
    `업체일련번호` bigint   not null,
    primary key (`발주일련번호`)
);

1) 작업: 발주시 일일발주회차 테이블에 insert 후 일일발주회차 일련번호를 발주 테이블에 update
2) 장점: 발주 테이블에 일일발주회차 일련번호 필드 추가 필요
3) 단점: 발주 원복시 해당 테이블을 신경쓰지 않아도 됨

 

# 1:1 관계 테이블

create table `일일발주회차`
(
    `발주일련번호` bigint      not null auto_increment,
    `발주회차`   tinyint     not null default 1,
    `발주일시`   datetime    not null,
    `발주번호`   varchar(50) not null,
    primary key (`발주일련번호`)
);

1) 작업: 발주시 일일발주회차 테이블에 각 발주번호마다 insert

2) 장점: 발주 테이블에 필드 추가 불필요

3) 단점: 발주 원복시 해당 테이블의 시간을 업데이트 혹은 발주건을 삭제해야 함

 

 

기존 datetime 필드를 사용하는 것은 쿼리에 대한 부담이 있어 패스하고 테이블을 생성하는 방향으로 고려하기 시작했다. N:1 관계 테이블은 현재 2천 7백만 row 가 있는 발주 테이블에 회차 일련번호를 넣기 조심스러워 1:1 로 마음이 기울었다. 리뉴얼을 준비하고 있는 시스템에서는 해당 테이블이 필요없기 때문에 걷어내기에도 용이하다는 이점이 존재했다.

 

그렇게 검토했지만 ... 결론은 1, 2, 3 회차의 순서대로 등록 및 조회되는 것이 아닌 시분초를 인지할 수 있도록 하는 것으로 픽스가 되어 기존 필드를 사용해 발주의 시분초를 출력하기로 했다.

728x90

댓글