[레거시 정규화] DB 정규화 하기2

0. 개요 

레거시 db를 정규화 한다

이제 운영에 기존 레거시 데이터를 옮기기 위해서는 sql dump가 필요하다

구조는 https://gyeong99.tistory.com/139

[레거시 정규화] DB 정규화 하기1

여기서 설명한다

 

레거시 DB 정규화의 진짜 시간을 쏟은 부분은 기존 REQUEST 테이블 데이터를 새로운 구조로 안전하게 덤프하는 과정이다.

 

1. DATA dump

전제: 레거시 테이블 구조

기존 REQUEST 테이블은 이런 형태였다고 가정하자.

 

REQUEST

- request_id

- request_title

- request_content

 

 

- request_type

- request_status

- requester_id

- created_at

 

 

- approver_id

- approver_name

- approval_status

- approved_at

 

이 데이터를 아래 3개 테이블로 나누는 게 목표다.

• REQUEST_CONTENT
• REQUEST_INFO
• REQUEST_APPROVAL

 

이때, 다른서버로 부터 이관을 받아와야하기 때문에 쿼리로 insert 문을 짜서 하는건 불가능하다 

따라서 dump 파일을 생성할 필요가 있다

csv나 sql로 뽑을 수 있는데, 개인적으로 csv는 선호하지 않아 sql로 진행했다

아래에서 그 과정을 설명한다

 

2. data dump 하기 

1) sql 파일 dump

mysqldump -u user -p legacy_db legacy_request > legacy_request.sql

 

2) data 전송 

scp legacy_request.sql user@new-server:/tmp/

 

3) 임시 테이블 생성 - 기존 레거시 처럼 생성

CREATE TABLE legacy_request_temp (
    request_id BIGINT,
    request_title VARCHAR(255),
    request_content TEXT,
    request_type VARCHAR(50),
    request_status VARCHAR(50),
    requester_id BIGINT,
    requester_name VARCHAR(100),
    requester_dept VARCHAR(100),
    approver_id BIGINT,
    approver_name VARCHAR(100),
    approver_dept VARCHAR(100),
    approved_at DATETIME,
    created_at DATETIME
);

 

4) 정규화 한대로 데이터 이관

 

- request_content

INSERT INTO request_content (request_id, request_title, request_content)
SELECT
    request_id,
    request_title,
    request_content
FROM legacy_request_temp;

 

- request_info

INSERT INTO request_info (
    request_id,
    request_type,
    request_status,
    requester_id,
    created_at
)
SELECT
    request_id,
    request_type,
    request_status,
    requester_id,
    created_at
FROM legacy_request_temp;

 

- requeset_approval

INSERT INTO request_approval (
    request_id,
    approver_id,
    approval_status,
    approved_at
)
SELECT
    request_id,
    approver_id,
    request_status,
    approved_at
FROM legacy_request_temp
WHERE approver_id IS NOT NULL;

 

5) data 수 검증 

SELECT COUNT(*) FROM legacy_request_temp;
SELECT COUNT(*) FROM request_content;
SELECT COUNT(*) FROM request_info;

 

 

3. 고찰

제 2NF 까지는 진행되었고,  AI에게 물어보니 3NF의 방안도 고려해줬다

실제 사용자 정보만 저장한 테이블을 따로 만들어서 이행종속을 제거하는 것이다

실제 필요한지 여부는 고민해볼 필요가 있는 부분인것 같다

시스템에선 LDAPS를 적용하여 사용자 정보를 가져오기 때문에 불필요하다고 느꼈다 

그래서 매 요청건에 따라 사용자 id, 이름등을 다 저장하는 구조로 설계했는데, 장단점이 있는 것 같다

 

장점으로는 매 요청의 정보마다 보여주는 사용자 이름, id 등을 해당 시스템의 범위 내에서 해결이 된다는 점이다

단점일지 장점일지 판단이 어려운 부분은, 이슈 케이스마다 다른데 매해 조직변경이 있는데 최신이 아니라 이력의 형태로 저장되는 것이다 

아직까지는 이 구조가 연동된 시스템까지 고려하여 최선의 결론인 것 같다

추후 시스템이 다른것과 연동이 필요하고 성능 개선이 필요하거나 한 시점이 오게되면 다시 구조를 변경해봐야할 것 같다

 

이제 이 다음으로 고려할 문제는 indexing이다 

매번 요청 정보를 불러올때, 요청과 관련한 관리 통계를 낼때 데이터가 늘어날 수록 점점 느려질 수 밖에 없을 것 이다 

다음 글에서는 indexing에 대한 정보와 공부한 내용에 대해서 정리해볼 예정이다