MySQL(DB)

[바미] MySQL - 프로시저에 대해 알아봅시다.

Bami 2024. 3. 28. 09:26
728x90
반응형

서론

오늘은 DB 프로시저에 대해 알아보도록 하겠습니다.

간혹 REST API를 처리할 때 사용하기도 하는데 이 프로시저가 어떤 상황에서 유리할 수 있는지 알아보도록 하겠습니다.

DB 프로시저?

DB 프로시저(Database Procedure)로 부르기도 하고, 저장 프로시저(Stored Procedure)라고 부르기도 하는데

쉽게 설명해서 데이터베이스에서 실행되는 일련의 SQL 문과 선택적 제어문의 집합을 의미합니다.

 

이러한 프로시저는 특정 작업을 수행하기 위해 SQL 문을 하나의 실행 가능한 블록으로 그룹화 하는데

DB 프로시저는 데이터베이스시스템 내부에 저장되어 있으며, 필요할 때마다 호출하여 사용할 수 있습니다.

프로시저는 데이터 검증, 데이터베이스 내 연산 수행, 복잡한 비즈니스 로직 실행 등에 사용됩니다.

 

DB 프로시저의 예시

아래 예시는 고객의 정보를 데이터베이스에 추가하는 프로시저의 예시입니다.

CREATE PROCEDURE AddCustomer
    @CustomerName VARCHAR(100),
    @ContactName VARCHAR(100),
    @Country VARCHAR(50)
AS
BEGIN
    INSERT INTO Customers (CustomerName, ContactName, Country)
    VALUES (@CustomerName, @ContactName, @Country);
END;

위의 예시에서 AddCustomer라는 이름의 프로시저를 생성하고 있습니다. 이 프로시저는 CustomerName, ContactName, Country라는 세 개의 매개변수를 받아, 이를 Customers 테이블에 새로운 레코드로 추가합니다.

프로시저 내의 BEGIN과 END 사이에 있는 SQL 문은 프로시저가 호출될 때 실행하죠.

 

이제 이 AddCustomer이라는 프로시저를 실행해주어야 합니다.

EXEC AddCustomer 'Samsung Electronics', 'Kim Ba-mi', 'South Korea';

DB 프로시저 사용의 장점

성능 향상

프로시저는 데이터베이스 서버에서 실행되므로, 데이터를 애플리케이션 서버로 전송하는 데 필요한 시간이 줄어듭니다.
그렇기 때문에 복잡한 쿼리나 대량의 데이터 처리가 필요할 때 특히 효과적이죠.

로직의 중앙화

비즈니스 로직을 데이터베이스에 중앙화함으로써, 어플리케이션의 여러 부분에서 동일한 로직을 재사용할 수 있습니다.

이는 코드의 일관성을 유지하고 유지보수를 용이하게 하죠.

보안 강화

프로시저를 사용하면, 사용자가 직접 테이블에 접근하는 것이 아니라 정의된 인터페이스를 통해 데이터에 접근합니다.

이는 데이터 접근을 더 잘 제어하고, SQL 주입 공격과 같은 보안 위험을 줄일 수 있어요.

트랜잭션 관리

프로시저 내에서 여러 SQL 문을 하나의 트랜잭션으로 그룹화할 수 있습니다. 이는 복잡한 작업을 안정적으로 처리하는 데 도움이 돼요.

DB 프로시저 사용의 단점

플랫폼 종속성

DB 프로시저는 구현된 데이터베이스 관리 시스템(DBMS)의 특정 문법과 기능에 의존합니다. 

예를 들어, Oracle의 PL/SQL, Microsoft SQL Server의 T-SQL 등이 있는데 이러한 종속성은 데이터베이스 시스템을 변경하거나

다른 DBMS로 마이그레이션할 경우 프로시저를 재작성 해야 하는 번거로운 일이 생겨버려요.

 

이 때 만약 비즈니스 로직이 프로시저 내에 심층적으로 구현되어 있을 경우, 시스템 간 호환성 문제가 발생할 수 있어 마이그레이션

과정이 매우 복잡해집니다.

복잡성 증가

위 예시로 알 수 있듯이 DB 프로시저는 로직이 데이터베이스 내부에 캡슐화되어 있기 때문에, 애플리케이션 로직과 분리되어 있습니다. 이는 데이터베이스 로직과 애플리케이션 로직 간의 경계를 모호하게 만들 수 있으며, 프로젝트의 복잡성을 증가시키게 되죠.

 

또한, 프로시저 내부의 로직이 복잡해질수록, 디버깅과 유지보수가 어려워지기 때문에 프로시저 부분에 문제가 생겼을 때

개발자가 문제를 진단하고 수정하기 위해서 데이터베이스의 특정 지식이 필요하기 때문에 문제를 해결하거나 유지보수가 들어갈 때 굉장히 복잡해집니다.

버전 관리의 어려움

코드 기반의 애플리케이션은 Git과 같은 버전 관리 시스템을 사용하여 효율적으로 관리할 수 있지만, DB 프로시저는 이러한 시스템과의 통합이 어렵습니다.

 

프로시저의 변경 사항을 추적하고, 여러 버전을 관리하며, 협업 과정에서 변경 사항을 통합하는 것은 훨씬 복잡한 작업이 되어 버리죠.

특히 대규모 팀이나 복잡한 프로젝트에서 협업할 때 변경 관리가 상당히 어렵습니다.

그럼 어떤 상황에서 DB 프로시저를 사용해야 할까요?

이러한 단점에도 불구하고, DB 프로시저는 복잡한 비즈니스 로직을 데이터베이스 레벨에서 처리해야 할 때, 데이터 처리의 성능을 최적화하고자 할 때, 또는 보안 요구 사항이 높아 직접적인 데이터베이스 액세스를 제한해야 할 때 유용한 기능 중에 하나에요.

 

중요한 것은 프로젝트의 요구 사항과 팀의 전문성을 고려하여 DB 프로시저의 사용 여부를 결정하는 것이 가장 현명합니다.

728x90
반응형