이것은 MySQL 저장 프로 시저를 논리적으로 사용합니까?

Question

나는 정말로 간단한 저장 프로 시저를 추가하도록 개발자가 계속 요청하는 호스팅 된 MySQL 데이터베이스가있는 클라이언트를 가지고 있습니다. 이런 저장 프로 시저를 살펴보면 저장 프로 시저로 구현되고 응용 프로그램 코드 내에서 구현되지 않는 이유는 알 수 없습니다. 이것이 실제로 저장 프로 시저의 이상한 사용이라는 것을 수정합니까?

CREATE DEFINER = 'username'@'%' PROCEDURE `sp_get_payrollgl`(IN pi_glcode TEXT) 
    DETERMINISTIC 
    CONTAINS SQL 
    SQL SECURITY INVOKER 
    COMMENT '' 
BEGIN 

    if (pi_glcode is null || pi_glcode = '') then 
    select glcode,descr, 
     case when crdb = 1 then 'CR' else 'DB' end as 'crdb', 
     case when taxable = 1 then 'Yes' else 'No' end as 'taxable', 
     case when billable = 1 then 'Yes' else 'No' end as 'billable', 
     case when active = 1 then 'Yes' else 'No' end as 'active' 
    from payrollgl; 
    else 
    select glcode,descr, 
     case when crdb = 1 then 'CR' else 'DB' end as 'crdb', 
     case when taxable = 1 then 'Yes' else 'No' end as 'taxable', 
     case when billable = 1 then 'Yes' else 'No' end as 'billable', 
     case when active = 1 then 'Yes' else 'No' end as 'active' 
    from payrollgl where glcode = pi_glcode; 
    end if; 
END; 

Answer 1

이와 같은 간단한 루틴의 경우, 나는 소리가 나지 않습니다. 이 특정 저장 프로 시저의 개체를 구성하는 데 더 좋은 방법이 있습니다. 예를 들어 구성 파일에 미리 정의되어 있거나 정의 된 배열 개체로 저장되어있는 경우입니다.

개인적으로 필자는 백 엔드에서 발생해야하는 복잡한 명령 집합, 특히 다른 테이블에서 많은 양의 데이터를 조작해야하는 경우 개인적으로 저장 프로 시저를 구현합니다. 이점은 분명히 데이터베이스에 대한 왕복 및 연결이 너무 많아서 발생하는 오버 헤드를 최소화 할 수 없다는 것입니다.

가끔 프런트 엔드 개발자로부터 복잡한 세부 사항이나 내부 동작을 캡슐화하기 위해 비즈니스 로직을 정의하는 저장 프로 시저를 사용하는 경우가 있습니다. 또 다른 이점은 시스템을 올바르게 설계하면 저장 프로 시저를 사용하여 시스템이 가능한 것으로 생각되는 것보다 훨씬 확장 성이 높다는 것입니다.

QAT에서 UAT로 개발과 같은 다양한 환경에서 개발할 때 특히 도움이됩니다. 어딘가에있는 서비스의 코드 줄을 변경해야 할 경우 해당 코드를 제거하고 변경 사항을 적용하기 위해 다시 배포하면 많은 혼란을 야기 할 수 있습니다. 저장 프로 시저를 사용하면 간단하게 변경할 수 있습니다. 행운을 빕니다!