[데이터베이스] DB에서 FK 설정 하지 않는 이유와 무결성 관리하는 방안

FK 설정하지 않는 이유

1. 성능상의 이유

INSERT / UPDATE 성능 저하

FK 제약 조건을 설정하면
데이터베이스는 참조 무결성을 유지하기 위해 관련 테이블의 데이터를 항상 확인해야 하므로

데이터 삽입(insert)이나 갱신(update) 성능이 저하될 수 있다.

 

따라서, 대량 데이터 처리가 일어나는 경우 FK로 인한 무결성 검사 때문에 처리 속도가 느려질 수 있다.

 

 

2. 복잡한 참조 관계와 유연성 부족

 

FK가 많은 테이블 구조는 설계가 복잡해지고, 이를 수정하거나 확장할 때 어려움이 생길 수 있다.

예를 들어, 참조 무결성을 유지하려면 부모 데이터를 삭제하기 전에 자식 데이터를 먼저 삭제해야 한다.

 

테이블 구조가 자주 변경되거나 확장이 필요한 경우, FK는 불필요한 제약이 될 수 있다. 

 

 

FK로 인해 테이블 간 의존성이 강해지며, 테이블 간의 결합도 증가로 인해 데이터 구조를 변경하기 어려워질 수 있다.

 

3. 분산 시스템에서의 제약

• 마이크로서비스 및 분산 시스템
  테이블이 서로 다른 데이터베이스에 분산되어 있는 경우, FK 설정이 불가능하다. 이러한 상황에서는 데이터 무결성을 애플리케이션에서 처리하거나 다른 방법(예: 이벤트 기반 시스템)으로 관리해야한다.

 

4. 테스트와 데이터 이관

• 데이터 이관(Migration)
  기존 데이터를 새로운 스키마로 이동하거나 대량으로 데이터를 초기화할 때 FK 제약 조건이 있으면 복잡도가 증가한다.
• 테스트 데이터 생성
  테스트 환경에서 데이터를 삽입하거나 조작할 때 FK가 설정되어 있으면 자유롭게 데이터 작업을 수행하기 어렵다.

 

5. 실제 비즈니스 요구

• 무결성이 크게 중요하지 않은 경우:
  데이터 무결성이 상대적으로 덜 중요한 상황(예: 로그 데이터, 캐싱 데이터 등)에서는 FK를 설정하지 않는 것이 합리적일 수 있다.

 

 

---

참조 무결성 관리하는 방안

1. 애플리케이션 레벨에서 데이터 삽입/갱신/삭제 시 참조 무결성을 확인하는 로직을 작성한다. 

예를 들어, 자식 데이터를 삽입하기 전에 부모 데이터가 존재하는지 확인하는 코드를 작성한다.

 

2. 데이터베이스 트리거를 설정하여 참조 데이터의 존재 여부를 확인한다.

부모 테이블의 데이터가 삭제되기 전에 관련 자식 테이블에 데이터가 있는지 확인하는 트리거를 작성한다. 

 

CREATE OR REPLACE TRIGGER check_parent_exists
BEFORE INSERT ON child_table
FOR EACH ROW
BEGIN
  IF NOT EXISTS (
    SELECT 1
    FROM parent_table
    WHERE id = :NEW.parent_id
  ) THEN
    RAISE_APPLICATION_ERROR(-20001, 'Parent does not exist.');
  END IF;
END;

 

3. 배치 작업을 통한 무결성 유지 

SELECT child_table.id
FROM child_table
LEFT JOIN parent_table
ON child_table.parent_id = parent_table.id
WHERE parent_table.id IS NULL;

 

4. 애플리케이션에서 데이터베이스 ORM 사용

@Entity
public class Child {
    @ManyToOne
    @JoinColumn(name = "parent_id", nullable = false)
    private Parent parent;
}

 

5. 이벤트 기반 아키텍처 : 마이크로서비스나 분산 시스템 환경

 

6. 제약 조건을 사용하지 않는 테이블 설계

데이터 무결성을 암시적으로 설계 >>
부모/자식 테이블에서 제약 조건 없이 데이터를 관리하되, 데이터 모델 설계를 통해 무결성을 암시적으로 유지한다.