기타

프로시저 및 트리거 사용을 권장하지 않는 경우

greeniti 2024. 12. 24. 22:14

최근 데이터베이스 및 애플리케이션 설계에서 Oracle과 같은 RDBMS에서 프로시저 및 트리거 사용을 권장하지 않는 경우가 종종 있습니다. 이는 특정 환경과 설계 철학의 변화로 인한 것이며, 그 배경에는 여러 가지 이유와 대안이 있습니다.

프로시저 사용 권장 하지 않는 이유

  1. 비즈니스 로직의 분리 필요
    • 현대적인 애플리케이션 설계에서는 비즈니스 로직을 데이터베이스(프로시저)보다는 애플리케이션 계층(서버 코드)에서 처리하도록 권장합니다.
    • 이는 코드 가독성, 테스트, 디버깅 및 유지보수성을 향상시키는 데 도움을 줍니다.
  2. 멀티 플랫폼 지원의 어려움
    • 프로시저는 특정 데이터베이스 시스템(Oracle, MySQL 등)에 종속됩니다.
    • 애플리케이션이 여러 데이터베이스를 지원해야 할 경우, 데이터베이스 종속적인 코드는 이식성이 떨어집니다.
  3. 확장성 문제
    • 클라우드 기반 환경이나 마이크로서비스 구조에서는 데이터베이스가 주로 데이터 저장에 집중하고, 비즈니스 로직은 별도의 서비스에서 처리하는 것이 일반적입니다.
    • 프로시저는 데이터베이스 부하를 증가시킬 수 있어 확장성을 저하시킬 가능성이 있습니다.
  4. 디버깅 및 테스트의 어려움
    • 프로시저 내의 로직은 일반적인 애플리케이션 코드보다 디버깅과 테스트가 어렵습니다.
    • 특히, 버전 관리나 테스트 자동화 도구와의 통합이 제한적입니다.
  5. 데이터베이스 락 및 동시성 이슈
    • 프로시저에서 복잡한 트랜잭션을 처리하는 경우, 잠금 문제나 성능 병목이 발생할 수 있습니다.
  6. CI/CD와의 통합 제한
    • 현대적인 DevOps 환경에서는 코드 배포가 자동화되어야 하지만, 데이터베이스 프로시저는 일반 애플리케이션 코드처럼 쉽게 통합하기 어렵습니다.

프로시저 대신 권장되는 대안

  1. 애플리케이션 계층에서 처리
    • 비즈니스 로직은 Python, Java, Node.js, .NET 등 애플리케이션 레이어에서 처리하도록 설계.
    • 데이터베이스는 단순히 데이터 저장, 검색 및 트랜잭션 관리를 담당.
  2. ORM (Object-Relational Mapping) 사용
    • Hibernate, Django ORM, SQLAlchemy와 같은 ORM 도구를 사용하여 데이터베이스 작업을 추상화.
    • 이식성과 유지보수성을 향상시킴.
  3. 마이크로서비스 아키텍처
    • 데이터베이스와 비즈니스 로직을 분리하여 각각 독립적으로 확장 가능하게 설계.
  4. Stored Procedure 최소화
    • 프로시저를 사용해야 하는 경우, 데이터 무결성 보장이나 성능 최적화 등 특정 목적으로 제한적으로 사용.
  5. 데이터 처리 전용 엔진
    • 대량의 데이터 처리를 위해 ETL 도구(Talend, Informatica 등)나 데이터 분석 플랫폼(Spark, BigQuery 등)을 사용.

프로시저 사용이 여전히 유효한 경우

권장하지 않는 경향이 있지만, 특정한 경우에는 프로시저를 사용하는 것이 여전히 유용합니다.

  1. 데이터베이스와 밀접한 작업
    • 데이터베이스 레벨에서의 복잡한 계산이나 집계 작업.
    • 예: 대규모 OLAP 시스템에서의 데이터 처리.
  2. 보안
    • 데이터베이스 내부에서만 실행되어야 하는 민감한 로직(예: 암호화, 데이터 접근 제한).
  3. 네트워크 부하 감소
    • 애플리케이션과 데이터베이스 간의 통신을 최소화하기 위해 다량의 데이터를 데이터베이스 내부에서 처리.

결론

프로시저 사용을 권장하지 않는 것은 트렌드와 설계 철학의 변화에서 비롯된 것이지만, 특정 상황에서는 여전히 유용할 수 있습니다. 따라서, 사용 여부는 시스템의 요구사항, 설계 목표, 성능, 유지보수성 등을 종합적으로 고려하여 결정해야 합니다.