4.6 KiB
4.6 KiB
결정 필요: DB 및 도메인 구조
자료에 테이블·스키마 정의가 없어 설계 결정이 필요한 항목.
1. 지자체 저장 방식
상황: 기능목록에는 "지자체별 단가", "지자체별 담당자", "소속 지자체 설정" 등 지자체 단위 관리가 나오나, 지자체를 저장하는 테이블/키에 대한 기술이 없음.
결정 필요:
- 지자체를 별도 테이블(
local_government또는organization등)로 두고 PK(예:lg_idx)로 관리할지, 아니면 코드(구/군 코드)만 쓰고 테이블은 두지 않을지. - 지자체 테이블을 둔다면 컬럼: 지자체명, 시/도, 구/군, 사용 여부 등 어떤 항목을 넣을지.
- 다중 지자체를 한 시스템에서 관리하는지(멀티테넌트), 아니면 1개 지자체 1 인스턴스로 배포할지.
참고: 발주·단가·지정판매소 조회 등에서 "구/군 코드", "동 코드"가 등장. 지자체 = 시/도·구/군 레벨로 해석 가능.
2. 지정판매소 테이블 및 지자체 연결
상황: 웹 기능목록에 지정판매소 등록 항목(상호명, 사업자번호, 주소, 구코드, 가상계좌 등)은 나오나 테이블명·전체 컬럼·DDL은 없음.
결정 필요:
- 테이블명: 예)
designated_shop,shop등. PK 컬럼명(예:ds_idx,shop_idx). - 지자체(또는 구/군)와의 연결: 지정판매소가 어느 지자체(구/군) 소속인지 저장할 컬럼 — 지자체 PK FK, 또는 구코드/동코드만 저장할지.
- 판매소번호 규칙: "기본코드 B, C, D + 판매소 일련번호" — 기본코드 B/C/D는 어디서 오는지(기본코드 테이블? 지자체별?).
- 결정됨: 일련번호는 지자체별로 부여. → 22-판매소번호_일련번호_결정.md
- 구코드: "판매소 주소를 바탕으로 기본코드 C 할당" — 기본코드 테이블이 있는지, 코드 체계(시/도/구/군/동)를 어떻게 저장할지.
3. 사용자(member)와 지자체·지정판매소 연결
상황: 지자체관리자는 "각 지자체에서" 접속, 지정판매소는 "지자체에 주문" — member가 어느 지자체/지정판매소에 소속되는지 자료에 명시 없음.
결정 필요:
- 지자체관리자(mb_level=3): 담당 지자체를 어떻게 저장할지.
- 예:
member에mb_lg_idx(지자체 FK) 추가, 또는member.mb_group에 지자체 코드 저장 등.
- 예:
- 지정판매소(mb_level=2): 담당 지정판매소 1개와 1:1 연결할지.
- 예:
member에mb_shop_idx(지정판매소 FK) 추가, 또는 지정판매소 테이블에mb_idx(로그인 회원 FK) 추가.
- 예:
- 일반 사용자(mb_level=1): 지자체/지정판매소 연결 필요 여부(앱 바코드 확인만 쓰는 경우 연결 없을 수 있음).
4. 그 외 엔티티 테이블
상황: 담당자, 업체, 판매 대행소, 무료용 대상자, 발주, 단가, 포장단위 등 지자체별 데이터가 나오나, 전부 테이블 구조 미정.
결정 필요:
- 담당자: 테이블 유무, 지자체 FK, 소속 종류(구/군/대행소/제작업체) 저장 방식.
- 업체(협회, 제작업체, 회수업체): 테이블 1개에 업체종류 구분할지, 테이블 분리할지. 지자체 FK.
- 판매 대행소: 테이블 정의, "소속 지자체 설정" 시 지자체 FK.
- 발주: 기능목록의 "발주 저장 테이블 컬럼"을 기준으로 테이블명·PK·타입 확정. 구/군 코드·동 코드는 어느 테이블(기본코드?)과 연결할지.
- 단가·포장단위: "지역별 봉투 코드" — 지역=지자체인지 구/군인지, 봉투 종류 테이블과의 관계.
5. 기본코드(기본코드 종류·세부 코드)
상황: "기본코드 종류" 시트 참고, "세부 기본코드" 시트 참고라고만 되어 있고, 테이블 구조·코드 체계는 자료에 없음.
결정 필요:
- 기본코드용 테이블 개수(종류 1개 + 세부 1개 등), PK/코드 컬럼 설계.
- 판매소번호·구코드에서 말하는 "기본코드 B, C, D"가 이 테이블과 동일한지, 코드 값 정의 주체(초기 데이터·마이그레이션).
정리: 지자체·지정판매소·사용자 연결·그 외 엔티티·기본코드까지 DB 구조를 한 번에 설계할지, 아니면 기능 단위(예: 지정판매소 관리 먼저) 로 테이블을 정해 나갈지도 결정이 필요함.