하루에 몇 번에 걸쳐 발주라는 처리가 진행되고 있다. 업체에서 이 데이터를 회차별로 조회할 수 있도록 하기 위한 기능 추가 요청이 들어왔고 이 회차가 업체별로 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 회차의 순서대로 등록 및 조회되는 것이 아닌 시분초를 인지할 수 있도록 하는 것으로 픽스가 되어 기존 필드를 사용해 발주의 시분초를 출력하기로 했다.
'Develop > Etc' 카테고리의 다른 글
Git 자주 사용하는 명령어 (0) | 2022.04.13 |
---|---|
npm ERR! Missing script: "build" (0) | 2022.04.13 |
테스트 커버리지? 개발하기 전에 테스트? (0) | 2022.03.29 |
PhpStorm Server returns invalid timezone. Go to 'Advanced' tab and set 'serverTimezone' property manually. (0) | 2020.03.08 |
Phpstorm 데이터베이스(Database) 연결 방법 (0) | 2020.03.07 |
댓글