1. 저장 프로시저는 매우 유용합니다. 예를 들어, 일반적인 로그인 시나리오에서는 사용자의 로그인 기록을 기록해야 합니다. 이를 달성하려면 프로그래밍 언어를 사용할 수 있습니다.
으아악
여기서 1단계에서는 먼저 사용자 존재 여부를 확인하고, 2단계에서는 사용자 로그인 로그를 기록합니다.
저장 프로시저 구현: login_user_and_save_result()의 기능은 사용자 로그인 작업을 수행하고 사용자의 로그인 로그를 기록하는 것입니다.
으아악
프로그래밍 언어 구현에는 2개의 데이터베이스 연결 연결 작업과 2개의 컴파일 SQL 작업이 필요하다는 점입니다. 매개변수만 전달하면 됩니다. 이와 같이 사용자 수가 점차 증가함에 따라 저장 프로세스는 서버의 대역폭과 시스템 리소스 소비를 많이 절약할 수 있으며 이점은 점차 나타날 것입니다.
상사가 로직을 추가하라고 하면 해당 사용자는 3번만 로그인이 허용됩니다. 3번 실패하면 해당 사용자는 로그인이 허용되지 않습니다. 프로그래밍 언어 수준의 데이터베이스 작업은 좀 더 복잡해집니다.
으아악
여기서 프로그래밍 언어는 DB에 자주 연결하거나 데이터베이스와 장기간 네트워크 연결을 유지해야 한다는 것을 알 수 있습니다. login_user_and_result()에서 이러한 모든 로그인 로직을 구현하는 경우 사용자 이름 매개변수를 전달하고 전달하기만 하면 시스템이 DB에 한 번만 연결하고 0번 컴파일하면 훨씬 간단해집니다.
2. 저장 프로시저의 역할은 리소스 소비에만 있는 것이 아닙니다. 이제 프로그램에는 두 가지 로그인 방법이 있습니다. 하나는 웹 측에 로그인하는 것이고, 다른 하나는 기본 클라이언트 측에 로그인하는 것입니다. 웹 측은 Java web을 사용하여 구현되고 클라이언트 측은 Visual C 를 사용하여 구현된다고 가정합니다. Java 웹 및 Visual C 모두 로그인 시 login_user_and_result()를 호출하면 사용자의 일관된 로그인 동작이 유지될 수 있으며 개발자는 별도 구현으로 인해 발생하는 다른 문제를 피할 수 있습니다. 실제로 다양한 데이터베이스 수준 권한을 저장 프로시저에 추가하여 로그인 권한을 균일하게 제어할 수도 있습니다.
저장 프로시저에는 두 가지 주요 장점이 있다고 생각합니다. 첫째, 네트워크 통신 오버헤드를 피하기 위해 데이터베이스 측에서 실행되므로 효율성이 높아집니다. 둘째, 저장 프로시저는 트랜잭션, 트리거, 다시 쓰기 규칙 등과 같이 데이터베이스에서 제공하는 일부 상위 수준 추상화를 직접 활용할 수 있습니다.
저장 프로시저를 전혀 사용하지 않으면 데이터베이스는 추가, 삭제, 수정을 제공하는 스토리지 백엔드일 뿐이며, 데이터베이스가 제공하는 고급 기능은 낭비됩니다. 저장 프로시저를 사용하여 비즈니스 기능을 구축할 수 있으며 프런트 엔드는 API의 효과와 유사하게 이러한 기능을 호출합니다.
제 프로젝트에서는 저장 프로시저를 많이 사용하는데, 특히 보고서의 경우 대부분 저장 프로시저를 사용합니다. 위의 장점 외에도 데이터베이스 간, 하위 테이블 통합, SQL의 일부 동적 접합 등 저장 프로시저의 확장성이 더 좋습니다. 저장 프로시저는 편리하고 직관적이며 사용됩니다. 향후 배포를 위해 저장 프로시저 내에서 수정 사항을 연결하기만 하면 됩니다.
저는 주로 데이터 정렬 및 마이그레이션에 사용합니다. 예를 들어 웹사이트를 수정하면 데이터 구조가 바뀌고, 특정 테이블이 분할되고, 특정 테이블이 병합되고, 특정 필드 데이터 형식이 변경되는 등의 문제가 발생합니다. 어쨌든 사이트가 업그레이드될 때만 사용하면 됩니다. 일반적으로 코드를 사용하여 구현할 수 있는 다른 쿼리는 저장 프로시저를 사용하여 구현하고 싶지 않습니다
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
1. 저장 프로시저는 매우 유용합니다. 예를 들어, 일반적인 로그인 시나리오에서는 사용자의 로그인 기록을 기록해야 합니다. 이를 달성하려면 프로그래밍 언어를 사용할 수 있습니다.
으아악여기서 1단계에서는 먼저 사용자 존재 여부를 확인하고, 2단계에서는 사용자 로그인 로그를 기록합니다.
저장 프로시저 구현: login_user_and_save_result()의 기능은 사용자 로그인 작업을 수행하고 사용자의 로그인 로그를 기록하는 것입니다.
으아악프로그래밍 언어 구현에는 2개의 데이터베이스 연결 연결 작업과 2개의 컴파일 SQL 작업이 필요하다는 점입니다. 매개변수만 전달하면 됩니다.
이와 같이 사용자 수가 점차 증가함에 따라 저장 프로세스는 서버의 대역폭과 시스템 리소스 소비를 많이 절약할 수 있으며 이점은 점차 나타날 것입니다.
상사가 로직을 추가하라고 하면 해당 사용자는 3번만 로그인이 허용됩니다. 3번 실패하면 해당 사용자는 로그인이 허용되지 않습니다. 프로그래밍 언어 수준의 데이터베이스 작업은 좀 더 복잡해집니다.
으아악여기서 프로그래밍 언어는 DB에 자주 연결하거나 데이터베이스와 장기간 네트워크 연결을 유지해야 한다는 것을 알 수 있습니다. login_user_and_result()에서 이러한 모든 로그인 로직을 구현하는 경우 사용자 이름 매개변수를 전달하고 전달하기만 하면 시스템이 DB에 한 번만 연결하고 0번 컴파일하면 훨씬 간단해집니다.
2. 저장 프로시저의 역할은 리소스 소비에만 있는 것이 아닙니다. 이제 프로그램에는 두 가지 로그인 방법이 있습니다. 하나는 웹 측에 로그인하는 것이고, 다른 하나는 기본 클라이언트 측에 로그인하는 것입니다. 웹 측은 Java web을 사용하여 구현되고 클라이언트 측은 Visual C 를 사용하여 구현된다고 가정합니다. Java 웹 및 Visual C 모두 로그인 시 login_user_and_result()를 호출하면 사용자의 일관된 로그인 동작이 유지될 수 있으며 개발자는 별도 구현으로 인해 발생하는 다른 문제를 피할 수 있습니다. 실제로 다양한 데이터베이스 수준 권한을 저장 프로시저에 추가하여 로그인 권한을 균일하게 제어할 수도 있습니다.
저장 프로시저에는 두 가지 주요 장점이 있다고 생각합니다. 첫째, 네트워크 통신 오버헤드를 피하기 위해 데이터베이스 측에서 실행되므로 효율성이 높아집니다. 둘째, 저장 프로시저는 트랜잭션, 트리거, 다시 쓰기 규칙 등과 같이 데이터베이스에서 제공하는 일부 상위 수준 추상화를 직접 활용할 수 있습니다.
저장 프로시저를 전혀 사용하지 않으면 데이터베이스는 추가, 삭제, 수정을 제공하는 스토리지 백엔드일 뿐이며, 데이터베이스가 제공하는 고급 기능은 낭비됩니다. 저장 프로시저를 사용하여 비즈니스 기능을 구축할 수 있으며 프런트 엔드는 API의 효과와 유사하게 이러한 기능을 호출합니다.
구현, 운영, 유지 관리는 스스로 변경할 수 있습니다. 그렇지 않은 경우 대기업의 경우 개발 측으로 돌아가서 코드를 변경하고 컴파일하고 패치를 발행해야 합니다
내 프로젝트에서는 저장 프로시저가 사용되지 않습니다. 뷰를 이용했어요! 대규모 프로젝트를 진행하는 회사는 필요한 경우 전담 DBA 부서를 보유할 수 있습니다!
ODS, 데이터 웨어하우스와 같은 기존 데이터 센터의 데이터 일괄 처리 또는 OLA는 계속해서 저장 프로시저를 사용합니다.
일부 DBA는 저장프로시저나 간단한 로직을 사용하여 로그를 데이터베이스에 기록하는데... 개인적으로는 코드로 작성하는 것이 더 쉽다고 생각합니다
효율성이 높으며 때로는 책임이 매우 세부적인 경우 백엔드가 마음대로 데이터베이스에 액세스하지 못할 수도 있습니다.
제 프로젝트에서는 저장 프로시저를 많이 사용하는데, 특히 보고서의 경우 대부분 저장 프로시저를 사용합니다.
위의 장점 외에도 데이터베이스 간, 하위 테이블 통합, SQL의 일부 동적 접합 등 저장 프로시저의 확장성이 더 좋습니다. 저장 프로시저는 편리하고 직관적이며 사용됩니다. 향후 배포를 위해 저장 프로시저 내에서 수정 사항을 연결하기만 하면 됩니다.
저는 주로 데이터 정렬 및 마이그레이션에 사용합니다. 예를 들어 웹사이트를 수정하면 데이터 구조가 바뀌고, 특정 테이블이 분할되고, 특정 테이블이 병합되고, 특정 필드 데이터 형식이 변경되는 등의 문제가 발생합니다. 어쨌든 사이트가 업그레이드될 때만 사용하면 됩니다. 일반적으로 코드를 사용하여 구현할 수 있는 다른 쿼리는 저장 프로시저를 사용하여 구현하고 싶지 않습니다
명망 있는 회사에서는 DBA와 같은 직책을 맡게 되며 프로그래머가 작성한 SQL을 무시하고 수천 줄의 저장 프로시저를 작성하여 복잡한 비즈니스를 구현하게 됩니다.
저장 프로시저 자체의 장점은 자세히 설명되어 있지 않습니다.