# 추출된 DDL (wace_plm 운영 DB) — 프로젝트관리(P2)

> 추출일: 2026-05-11
> 출처: `211.115.91.141:11133/waceplm` (PostgreSQL 16.8)
> 적용 대상: `211.115.91.141:11134/vexplor_rps`
> 추출 방법: information_schema 쿼리 (pg_dump 14.19 ↔ 16.8 버전 불일치로 직접 추출 불가 — 영업관리 패턴과 동일)

vexplor_rps에 부재한 WBS 계열 8개 테이블을 운영DB에서 추출해 P2(WBS관리)용 베이스 스키마 구성.

## 파일

| 파일 | 테이블 | 컬럼 | 운영 데이터 |
|---|---|---:|---:|
| `200_pms_wbs.sql` | `pms_wbs_task` (트리 — 설계/구매/제작/자체검사/최종검사/출하/셋업) | 58 | 0건 |
|   | `pms_wbs_task_info` (**일반 task 리스트 — 실사용**) | 22 | 518건 |
|   | `pms_wbs_task_confirm` (작업 확정, objid numeric) | 7 | 0건 |
|   | `pms_wbs_task_standard` (트리 표준) | 10 | 5건 |
|   | `pms_wbs_task_standard2` (**일반 task 표준 — 실사용**) | 20 | 74건 |
|   | `pms_wbs_template` (제품별 템플릿) | 6 | 1건 |
|   | `setup_wbs_task` (**셋업 진척 — 최다 사용**) | 20 | 2,576건 |
|   | `setup_wbs_task_standard` (셋업 표준) | 19 | 46건 |

운영 컬럼 합 162개 / vexplor_rps 적용 후 162개 — 100% 일치 확인.

## 핵심 발견

### 1. 두 갈래 WBS 구조 (트리 vs 평면 리스트)

운영DB에 **두 종류 task 테이블이 공존**:

| 갈래 | 구조 | 운영 데이터 |
|---|---|---|
| **`pms_wbs_task` + `_standard`** | parent_objid 트리 / 단계별(설계/구매/제작/자체검사/최종검사/출하/셋업) plan/act/rate 컬럼 | 0건 / 5건 ← **사실상 미사용** |
| **`pms_wbs_task_info` + `_standard2`** | 평면 리스트 / task_step+task_seq 정렬 / PM 승인 흐름 | 518건 / 74건 ← **실사용** |

→ **운영판이 실제 어느 화면에서 어느 갈래를 쓰는지** wace JSP 분석 + 운영판 화면 캡처로 결정해야 함. `_info` 갈래가 데이터량 압도적이라 메인 후보지만, JSP 화면이 `pms_wbs_task`(트리)를 가리킬 가능성도 있음 — 두 갈래 모두 분석.

### 2. setup_wbs_task가 진척율 데이터 (P1 진행관리 그리드와 연결)

`setup_wbs_task` 2,576건이 운영에서 가장 큰 WBS 데이터. 진행관리 P1 그리드 컬럼 `제조1,2팀 / 제조3팀 / 조립 / 검증 / 출하일` 자리가 P1에선 빈 자리였는데, **이게 setup_wbs_task에서 채워지는 데이터**일 가능성 높음 (P1 GAP 문서 확인 필요).

### 3. 인덱스 명 typo

`setup_wbs_task_standard _objid_key` (`_standard` 뒤에 공백 한 칸) — 운영 그대로 1:1 보존 (`"…"` 따옴표 처리).

### 4. PK/UNIQUE 정책 일관성 없음

- PK: `pms_wbs_task_info`, `pms_wbs_task_standard`, `pms_wbs_template` (objid)
- UNIQUE 인덱스만: `pms_wbs_task`(wbs_task_pk), `setup_wbs_task`(setup_wbs_task_pk), `setup_wbs_task_standard`
- 제약 0: `pms_wbs_task_confirm`, `pms_wbs_task_standard2`

운영 1:1 보존. PostgreSQL 측에서는 UNIQUE 인덱스만 있어도 ON CONFLICT 등 동작에 영향 없음.

### 5. objid 채번 방식

운영DB에 WBS 시퀀스 없음 → wace Java 측에서 `UUID.randomUUID()` 또는 자체 시퀀스 함수로 생성한 문자열 사용. vexplor_rps에서는 nanoid/uuid 등 backend-node 측 채번 패턴 적용 예정 (영업관리 sales_no 패턴과는 다름).

## 운영 데이터 시드 (선택)

운영 데이터를 vexplor_rps에 가져오려면(데이터량 작은 표준/템플릿만):

```bash
# pg_dump 직접 사용 불가(버전 mismatch) — psql COPY 또는 INSERT 추출
PGPASSWORD='waceplm0909!!' psql -h 211.115.91.141 -p 11133 -U postgres -d waceplm \
  -c "COPY (SELECT * FROM pms_wbs_task_standard2) TO STDOUT WITH CSV HEADER" \
  > /tmp/pms_wbs_task_standard2.csv

PGPASSWORD='vexplor0909!!' psql -h 211.115.91.141 -p 11134 -U postgres -d vexplor_rps \
  -c "\COPY pms_wbs_task_standard2 FROM '/tmp/pms_wbs_task_standard2.csv' WITH CSV HEADER"
```

`setup_wbs_task` 2,576건도 동일 방식. 실 데이터 의존성(contract_objid가 운영 project_mgmt.objid를 참조) 때문에 vexplor_rps 측 데이터와 맞지 않을 가능성 — 시드는 화면 검증 단계에서 케이스별 판단.

## 추출 명령 재현

```bash
# 컬럼 정보
PGPASSWORD='waceplm0909!!' psql -h 211.115.91.141 -p 11133 -U postgres -d waceplm -t -A -F '|' -c "
SELECT table_name||'|'||ordinal_position||'|'||column_name||'|'||data_type||'|'||COALESCE(character_maximum_length::text,'')||'|'||COALESCE(numeric_precision::text,'')||'|'||COALESCE(numeric_scale::text,'')||'|'||is_nullable||'|'||COALESCE(column_default,'')
FROM information_schema.columns
WHERE table_schema='public'
  AND table_name IN ('pms_wbs_task','pms_wbs_task_info','pms_wbs_task_confirm','pms_wbs_task_standard','pms_wbs_task_standard2','pms_wbs_template','setup_wbs_task','setup_wbs_task_standard')
ORDER BY table_name, ordinal_position;"

# 제약조건
... information_schema.table_constraints JOIN key_column_usage

# 인덱스
... pg_indexes WHERE schemaname='public'

# 컬럼 코멘트
... information_schema.columns LEFT JOIN pg_statio_all_tables JOIN pg_description
```

## 적용

```bash
PGPASSWORD='vexplor0909!!' psql -h 211.115.91.141 -p 11134 -U postgres -d vexplor_rps \
  -v ON_ERROR_STOP=1 -f 200_pms_wbs.sql
```

8개 테이블 모두 IDEMPOTENT (`DROP TABLE IF EXISTS … CASCADE`로 재실행 안전).
