Stored Procs와 Code에서 SQL을 유지하기위한 장단점은 무엇입니까?

C # 소스 코드 또는 Stored Procs에서 SQL을 유지하는 장점 / 단점은 무엇입니까? 우리가 작업중 인 오픈 소스 프로젝트 (C # ASP.NET 포럼)에서 친구 와이 문제를 논의했습니다. 현재 대부분의 데이터베이스 액세스는 C #으로 SQL 인라인을 작성하고 SQL Server DB를 호출하여 수행됩니다. 따라서이 특정 프로젝트에 가장 적합한 프로젝트를 설정하려고합니다.

지금까지 나는 :

코드 내 장점 :

• 손쉬운 유지 관리-쿼리를 업데이트하기 위해 SQL 스크립트를 실행할 필요가 없습니다.
• 다른 DB로 쉽게 포팅 가능

저장된 Procs의 장점 :

• 공연
• 보안

나는 저장 프로 시저의 팬이 아니다

저장 프로시 저는 다음과 같은 이유로 유지 관리가 더 용이합니다. * 일부 SQL을 변경할 때마다 C # 앱을 다시 컴파일 할 필요가 없습니다.

어쨌든 데이터 유형이 변경되거나 여분의 열 등을 반환하려고 할 때 다시 컴파일하게됩니다. 앱 아래에서 SQL을 '투명하게'변경할 수있는 횟수는 전체적으로 매우 작습니다.

• 결국 SQL 코드를 재사용하게됩니다.

C #이 포함 된 프로그래밍 언어에는 함수라는 놀라운 기능이 있습니다. 여러 곳에서 동일한 코드 블록을 호출 할 수 있음을 의미합니다! 놀랄 만한! 그런 다음 재사용 가능한 SQL 코드를 이들 중 하나에 넣을 수 있습니다. 또는 첨단 기술을 원한다면이를위한 라이브러리를 사용할 수 있습니다. 나는 그것들이 객체 관계형 매퍼라고 불리우며 요즘 꽤 일반적입니다.

유지 관리 가능한 응용 프로그램을 만들려고 할 때 코드 반복은 최악의 일입니다!

저장 프로 시저가 나쁜 이유입니다. SQL보다 코드를 함수로 리팩토링 및 분해 (더 작은 부분으로 나눔)하는 것이 훨씬 쉽습니다.

동일한 SQL 코드를 사용하는 4 개의 웹 서버와 많은 Windows 응용 프로그램이 있습니다. 이제 SQl 코드에 작은 문제가 있음을 깨달았습니다. 웹 서버에서 모든 창 상자에 모든 데스크탑 응용 프로그램을 다시 설치하십시오 (clickonce가 도움이 될 수 있음)

Windows 앱이 중앙 데이터베이스에 직접 연결되는 이유는 무엇입니까? 서버 측 캐싱을 배제 할 때 병목 현상이 발생하는 것 같습니다. 웹 서비스를 통해 연결하거나 웹 서버와 유사하지 않아야합니까?

그렇다면 새 sproc 1 개 또는 새 웹 서버 4 개를 밀어?

이 경우 하나의 새로운 sproc을 푸시 하는 것이 더 쉽지만 내 경험상 '푸시 변경'의 95 %가 데이터베이스가 아닌 코드에 영향을 미칩니다. 해당 달에 웹 서버에 20 개를, 데이터베이스에 1 개를 푸시하는 경우 21 개를 웹 서버에 푸시하고 데이터베이스에 0을 푸시하면 크게 손실되지 않습니다.

보다 쉽게 ​​코드를 검토했습니다.

어떻게 설명 할 수 있습니까? 나는 이것을 얻지 못한다. 특히 sprocs가 소스 제어에없는 것으로 보이므로 웹 기반 SCM 브라우저 등을 통해 액세스 할 수 없습니다.

더 많은 단점 :

Storedproc은 데이터베이스에 존재하며 외부 세계에는 블랙 박스로 표시됩니다. 소스 컨트롤에 넣기를 원하는 것과 같은 간단한 일은 악몽이됩니다.

노력의 문제도 있습니다. CEO에게 왜 일부 포럼을 구축하는 데 7 백만 달러의 비용이 드는지 정당화하려는 경우 모든 것을 백만 계층 으로 나누는 것이 합리적 일 수 있습니다. 이익.

이것은 현재 몇 개의 다른 스레드에서 논의되고 있습니다. Linq to Sql에 대한 몇 가지 좋은 주장이 제시되었지만 저장 프로 시저의 일관된 제안자입니다.

코드에 쿼리를 포함하면 데이터 모델과 밀접하게 연결됩니다. 저장 프로시 저는 좋은 형태의 계약 프로그래밍입니다. 즉, 저장 프로 시저의 입력 및 출력으로 표시되는 계약이 유지되는 한 DBA는 프로 시저에서 데이터 모델 및 코드를 자유롭게 변경할 수 있습니다.

쿼리가 코드에 묻혀 있고 중앙에서 관리하기 쉬운 위치가 아닌 경우 프로덕션 데이터베이스 조정이 매우 어려울 수 있습니다.

[편집] 여기 또 다른 현재 토론이 있습니다.

제 생각에는이 질문에 대해 찬성 투표를 할 수 없습니다. 그것은 전적으로 응용 프로그램의 디자인에 달려 있습니다.

3 계층 환경에서 응용 프로그램 서버가있는 SP 사용에 대해 전적으로 투표합니다. 이러한 종류의 환경에서 비즈니스 로직을 실행하기 위해 응용 프로그램 서버가 있습니다. SP를 추가로 사용하는 경우 시스템 전체에 비즈니스 로직 구현을 배포하기 시작하고 누가 무엇을 담당하는지 명확하지 않게됩니다. 결국에는 기본적으로 다음을 수행하지 않는 응용 프로그램 서버가 생깁니다.

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

결국 16 개의 CPU가 장착 된이 멋진 4 개의 서버 클러스터에서 미들 티어를 실행하게되며 실제로 아무 것도 수행하지 않습니다! 정말 낭비입니다!

DB 또는 더 많은 응용 프로그램에 직접 연결하는 뚱뚱한 GUI 클라이언트가 있다면 다른 이야기입니다. 이 상황에서 SP는 응용 프로그램을 데이터 모델에서 분리하고 제어 가능한 액세스를 제공하는 일종의 의사 중간 계층 역할을 할 수 있습니다.

코드 내 장점 :

• 손쉬운 유지 관리-쿼리를 업데이트하기 위해 SQL 스크립트를 실행할 필요가 없습니다.
• 다른 DB로 쉽게 포팅 가능

사실, 나는 당신이 그것을 거꾸로 가지고 있다고 생각합니다. IMHO, 코드의 SQL은 다음과 같은 이유로 유지 관리가 어려움입니다.

• 관련 코드 블록에서 자신을 반복하게됩니다.
• SQL은 많은 IDE에서 언어로 지원되지 않으므로 작업을 수행하는 일련의 오류가없는 문자열이 있습니다.
• 데이터 유형, 테이블 이름 또는 제약 조건의 변경은 전체 데이터베이스를 새 데이터베이스로 바꾸는 것보다 훨씬 널리 퍼져 있습니다.
• 쿼리가 복잡 해짐에 따라 난이도가 높아집니다
• 인라인 쿼리를 테스트하려면 프로젝트를 빌드해야합니다.

Stored Procs는 데이터베이스 객체에서 호출하는 메소드로 생각하십시오. 재사용이 훨씬 쉽고, 편집 할 곳이 한 곳 뿐이며 DB 제공자를 변경하는 경우 변경 사항은 Stored Procs에서 발생하며 코드에서는 발생하지 않습니다. .

즉, Stu가 나에게 말한 것처럼 저장된 procs의 성능 향상은 최소이며 저장 프로 시저에 아직 중단 점을 둘 수는 없습니다.

범죄자

저장 프로 시저 내에서 많은 처리를 수행하면 DB 서버가 행동의 규모를 조정할 때 융통성이없는 단일 지점이 될 수 있습니다.

그러나 sql-server와 달리 프로그램에서 모든 크 런칭을 수행 하면 코드를 실행하는 여러 서버가있는 경우 더 확장 할 수 있습니다. 물론 이것은 일반적인 페치 또는 업데이트를 수행하는 저장된 procs에는 적용되지 않지만 데이터 세트를 반복하는 것과 같이 더 많은 처리를 수행하는 procs에는 적용되지 않습니다.

찬성

1. 가치있는 성능 (DB 드라이버에 의한 쿼리 파싱 / 계획 재생 등을 피함)
2. 데이터 조작은 C / C ++ / C # 코드에 포함되어 있지 않으므로 저수준 코드를 살펴볼 필요가 없습니다. SQL은 덜 장황하고 별도로 나열 될 때 쉽게 살펴볼 수 있습니다.
3. 분리 된 사람들로 인해 SQL 코드를 훨씬 쉽게 찾고 재사용 할 수 있습니다.
4. 스키마가 변경 될 때 내용을 변경하는 것이 더 쉽습니다. 코드에 동일한 출력을 주면됩니다.
5. 다른 데이터베이스로 쉽게 포팅 할 수 있습니다.
6. 저장 프로 시저에 대한 개별 권한을 나열하고 해당 수준에서도 액세스를 제어 할 수 있습니다.
7. 데이터 변환 코드와 별도로 데이터 쿼리 / 지속성 코드를 프로파일 링 할 수 있습니다.
8. 저장 프로 시저에서 변경 가능한 조건을 구현할 수 있으며 고객 사이트에서 쉽게 사용자 지정할 수 있습니다.
9. 자동화 된 도구를 사용하여 스키마와 명령문을 함께 코드로 변환하는 것이 아니라 코드 내에 포함시킬 때보 다 쉽게 변환 할 수 있습니다.
10. 단일 파일 내에 모든 데이터 액세스 코드가 있으면 데이터 액세스에 대한 모범 사례를보다 쉽게 ​​확보 할 수 있습니다. 비 성능 테이블에 액세스하거나 더 높은 수준의 직렬화를 사용하거나 코드에서 *를 선택하는 쿼리를 확인할 수 있습니다. .
11. 모든 파일이 하나의 파일에 나열되면 스키마 변경 / 데이터 조작 논리 변경을 쉽게 찾을 수 있습니다.
12. 동일한 위치에있을 때 SQL에서 편집을 쉽게 검색하고 바꾸는 것이 더 쉬워집니다 (예 : 저장된 모든 proc에 대한 트랜잭션 격리 명령문 변경 / 추가).
13. 나와 DBA 직원은 DBA가 내 SQL 항목을 검토해야 할 때 별도의 SQL 파일을 갖는 것이 더 쉽고 편리하다는 것을 알았습니다.
14. 마지막으로, 팀의 일부 게으른 구성원이 임베디드 SQL을 사용할 때 매개 변수화 된 쿼리를 사용하지 않았기 때문에 SQL 삽입 공격에 대해 걱정할 필요가 없습니다.

저장 프로 시저의 성능 이점은 종종 무시할 만합니다.

저장 프로 시저에 대한 추가 장점 :

• 리버스 엔지니어링 방지 (물론 암호화로 만든 경우)
• 데이터베이스 액세스의 중앙 집중화 향상
• 데이터 모델을 투명하게 변경하는 기능 (새 클라이언트를 배포하지 않고도) 여러 프로그램이 동일한 데이터 모델에 액세스하는 경우 특히 유용

나는 코드 쪽에 빠진다 . 모든 앱 (웹 및 클라이언트 모두)에서 사용하는 데이터 액세스 계층을 구축하므로 이러한 관점에서 DRY입니다. 테이블 스키마가 올바른지 확인하면되므로 데이터베이스 배포가 간단 해집니다. 소스 코드와 데이터베이스를 볼 필요가 없으므로 코드 유지 관리가 간소화됩니다.

데이터 모델과의 긴밀한 결합에는 큰 문제가 없습니다. 왜냐하면 실제로 결합을 끊을 수있는 곳을 알 수 없기 때문입니다. 응용 프로그램과 해당 데이터는 본질적으로 결합되어 있습니다.

저장 프로 시저

오류가 발생하거나 로직이 약간 변경되면 프로젝트를 다시 컴파일 할 필요가 없습니다. 또한 프로젝트에서 쿼리를 코딩 한 장소뿐만 아니라 다른 소스에서도 액세스 할 수 있습니다.

저장 프로 시저를 유지 관리하는 것이 더 어렵다고 생각하지 않으므로 데이터베이스에서 직접 코드를 작성하지 않고 별도의 파일로 먼저 코딩해야하며 설정 해야하는 모든 DB에서 실행할 수 있습니다.

저장 프로 시저의 장점 :

보다 쉽게 ​​코드를 검토했습니다.

결합이 적으므로 더 쉽게 테스트 할 수 있습니다.

더 쉽게 조정됩니다.

일반적으로 네트워크 트래픽의 관점에서 성능이 향상됩니다. 커서가 있거나 비슷한 경우 데이터베이스로 여러 번 이동하지 않습니다.

데이터에 대한 액세스를보다 쉽게 ​​보호하고 테이블에 대한 직접 액세스를 제거하고 프로세스를 통해 보안을 강화할 수 있습니다. 또한 테이블을 업데이트하는 코드를 비교적 빠르게 찾을 수 있습니다.

관련된 다른 서비스 (예 :보고 서비스)가있는 경우 모든 논리를 코드가 아닌 저장 프로 시저에 저장하는 것이 더 쉬울 수 있습니다.

단점 :

개발자를 위해 관리하기가 더 어렵습니다. 스크립트의 버전 제어 : 모든 사람이 자체 데이터베이스를 가지고 있습니까? 버전 제어 시스템이 데이터베이스 및 IDE와 통합되어 있습니까?

경우에 따라 코드에서 동적으로 생성 된 sql은 저장된 proc보다 성능이 더 좋습니다. 매우 유연해야하기 때문에 수십 개의 매개 변수로 극히 복잡한 스토어드 프로 시저 (sp_customersearch)를 작성한 경우 런타임시 코드에서 훨씬 더 간단한 SQL 문을 생성 할 수 있습니다.

이것은 단순히 일부 처리를 SQL에서 웹 서버로 옮기는 것이라고 주장 할 수 있지만 일반적으로 좋은 것입니다.

이 기술의 또 다른 장점은 SQL 프로파일 러를 보면 생성 한 쿼리를보고 20 개의 매개 변수가있는 저장된 proc 호출을 보는 것보다 훨씬 쉽게 디버깅 할 수 있다는 것입니다.

나는 저장된 procs를 좋아하는데, 응용 프로그램에 다운 타임을 발생시키지 않는 저장 프로 시저를 사용하여 응용 프로그램을 몇 번이나 변경할 수 있었는지 알 수 없습니다.

Transact SQL의 큰 팬, 큰 쿼리를 조정하는 것이 나에게 매우 유용한 것으로 입증되었습니다. 약 6 년 동안 인라인 SQL을 작성하지 않았습니다!

sprocs에 대한 2 개의 pro-point를 나열합니다.

성능-실제로는 아닙니다. Sql 2000 이상에서는 쿼리 계획 최적화가 훌륭하고 캐시됩니다. 오라클 등이 비슷한 일을 할 것이라고 확신합니다. 성능에 대한 sprocs가 더 이상 없다고 생각합니다.

보안? sproc가 더 안전한 이유는 무엇입니까? 어쨌든 보안이 철저하지 않은 데이터베이스가 없다면 모든 액세스는 DBA 또는 응용 프로그램을 통해 이루어집니다. 항상 모든 쿼리를 매개 변수화하십시오-사용자 입력에서 어떤 것도 인라인하지 마십시오.

어쨌든 성능에 대한 모범 사례입니다.

Linq는 확실히 지금 새로운 프로젝트를 진행할 방법입니다. 이 비슷한 게시물을 참조하십시오 .

K

보안? sproc가 더 안전한 이유는 무엇입니까?

Komradekatz에서 제안한대로 테이블에 대한 액세스를 허용하지 않고 (DB에 연결되는 사용자 이름 / 암호 콤보의 경우) SP 액세스 만 허용 할 수 있습니다. 이렇게하면 누군가 데이터베이스에 사용자 이름과 비밀번호를 가져 오면 SP를 실행할 수는 있지만 테이블이나 DB의 다른 부분에는 액세스 할 수 없습니다.

(물론 sprocs를 실행하면 필요한 모든 데이터를 얻을 수 있지만 사용 가능한 sproc에 따라 다릅니다. 테이블에 대한 액세스 권한을 부여하면 모든 것에 액세스 할 수 있습니다.)

이런 식으로 생각해

동일한 SQL 코드를 사용하는 4 개의 웹 서버와 많은 Windows 응용 프로그램이 있습니다. 이제 SQl 코드에 작은 문제가 있음을 깨달았습니다. 웹 서버에서 모든 창 상자에 모든 데스크탑 응용 프로그램을 다시 설치하십시오 (clickonce가 도움이 될 수 있음)

나는 저장된 procs를 선호합니다

또한 proc에 대해 성능 테스트를 수행하는 것이 더 쉬우 며 set showplan_text on 및 voila의 쿼리 분석기 세트 통계 io / time에 넣습니다.

정확히 무엇이 호출되는지 확인하기 위해 프로파일 러를 실행할 필요가 없습니다.

내 2 센트 만

나는 인라인 또는 임시가 아닌 ORM을 사용하여 코드로 유지하는 것을 선호하므로 .sql 파일 저장을 처리하지 않고도 소스 제어로 보호됩니다.

또한 저장 프로시 저는 본질적으로 더 안전하지 않습니다. 인라인처럼 쉽게 sproc를 사용하여 잘못된 쿼리를 작성할 수 있습니다. 매개 변수화 된 인라인 쿼리는 sproc만큼 안전 할 수 있습니다.

논리를 처리하는 가장 좋은 방법으로 앱 코드를 사용하십시오.
데이터를 저장하는 가장 좋은 방법으로 데이터베이스를 사용하십시오.

저장 프로 시저를 디버깅 할 수 있지만 코드에서 논리를 디버깅하고 유지 관리하기가 더 쉽습니다. 일반적으로 데이터베이스 모델을 변경할 때마다 코드 재 컴파일이 종료됩니다.

또한 선택 가능한 검색 매개 변수가있는 저장 프로시 저는 가능한 모든 매개 변수를 미리 지정해야하기 때문에 때때로 매개 변수가 seach에서 반복 될 횟수를 예측할 수 없으므로 복잡한 검색이 불가능합니다.

보안과 관련하여 저장 프로시 저는 훨씬 더 안전합니다. 어떤 사람들은 모든 액세스가 어쨌든 응용 프로그램을 통해 이루어질 것이라고 주장했습니다. 많은 사람들이 잊고있는 것은 대부분의 보안 침해가 회사 내부에서 발생한다는 것입니다. 응용 프로그램의 "숨겨진"사용자 이름과 암호를 알고있는 개발자는 몇 명입니까?

또한 MatthieuF가 지적했듯이 응용 프로그램 (데스크톱 또는 웹 서버에 있는지 여부)과 데이터베이스 서버 간의 왕복 횟수가 줄어들어 성능이 크게 향상 될 수 있습니다.

내 경험상 저장 프로 시저를 통한 데이터 모델의 추상화는 유지 관리 성을 크게 향상시킵니다. 과거에 많은 데이터베이스를 유지 관리해야했던 사람으로서, 필요한 모델 변경에 직면했을 때 간단히 저장 프로시 저나 두 개만 변경하고 변경 사항을 모든 외부 응용 프로그램에 완전히 투명하게 적용 할 수 있습니다. 많은 경우 응용 프로그램이 데이터베이스를 가리키는 유일한 것은 아닙니다. 다른 응용 프로그램,보고 솔루션 등이 있기 때문에 영향을받는 모든 지점을 추적하는 것은 테이블에 대한 개방적인 액세스로 번거로울 수 있습니다.

또한 SQL 프로그래밍을 전문으로하는 사람들에게 SQL 프로그래밍을 제공하기위한 플러스 열과 검사를 더욱 쉽게 분리하고 테스트 / 최적화 할 수있는 SP에 대해서도 점검 할 것입니다.

내가 볼 수있는 단점은 많은 언어가 테이블 매개 변수를 전달할 수 없기 때문에 알 수없는 데이터 값을 전달하는 것은 성 가실 수 있으며 일부 언어는 여전히 단일 저장 프로 시저에서 여러 결과 집합을 검색 할 수 없다는 것입니다. 후자는 SP와 관련하여 인라인 SQL보다 나쁘지 않습니다.

내가 참석 한 보안에 대한 Microsoft TechEd 세션의 제안 중 하나는 저장된 procs를 통해 모든 전화를 걸고 테이블에 대한 액세스를 거부합니다. 이 접근 방식은 추가 보안을 제공하는 것으로 청구되었습니다. 보안을 위해서만 가치가 있는지 확실하지 않지만 이미 저장된 procs를 사용하고 있다면 상처를 입을 수 없습니다.

저장 프로 시저에 넣으면 유지 관리가 훨씬 쉽습니다. 향후 변경 될 수있는 어려운 논리가있는 경우 여러 클라이언트가 연결되어있을 때 데이터베이스에 넣는 것이 좋습니다. 예를 들어, 최종 사용자 웹 인터페이스와 관리 데스크탑 응용 프로그램이있는 응용 프로그램을 작성 중입니다. 두 응용 프로그램 모두 데이터베이스를 분명히 공유하고 가능한 한 데이터베이스에 많은 논리를 유지하려고합니다. 이것은 DRY 원칙 의 완벽한 예입니다 .

저장된 프로 시저에서 동적 SQL을 속이고 사용하지 않는다고 가정하면 저장된 proc의 측면에 단단히 있습니다. 먼저, 저장된 procs를 사용하면 dba는 테이블 레벨이 아닌 저장된 proc 레벨에서 권한을 설정할 수 있습니다. 이것은 SQL 주입 공격에 대항 할뿐만 아니라 내부자가 데이터베이스에 직접 액세스하여 변경하는 것을 방지하는 데 중요합니다. 사기를 방지하는 데 도움이됩니다. 개인 정보 (SSN, 신용 카드 번호 등)가 포함되어 있거나 금융 거래를 생성하는 데이터베이스는 강제 절차를 제외하고는 액세스 할 수 없습니다. 다른 방법을 사용하는 경우 회사의 개인이 가짜 금융 거래를하거나 신원 도용에 사용할 수있는 데이터를 훔칠 수 있도록 데이터베이스를 넓게 열어 둡니다.

저장된 procs는 또한 앱에서 전송 된 SQL보다 유지 관리 및 성능 조정이 훨씬 쉽습니다. 또한 데이터베이스 구조 변경이 데이터 액세스 방식에 미치는 영향을 dba가 확인할 수 있습니다. 나는 데이터베이스에 동적으로 액세스 할 수있는 좋은 dba를 만난 적이 없다.

현재 작업중인 Oracle DB에서 저장 프로 시저를 사용합니다. 우리는 Subversion도 사용합니다. 모든 저장 프로시 저는 .pkb 및 .pks 파일로 만들어 Subversion에 저장됩니다. 전에 인라인 SQL을 해봤는데 고통입니다! 우리가 여기서하는 방식을 훨씬 선호합니다. 새로운 저장 프로 시저를 만들고 테스트하는 것이 코드에서 수행하는 것보다 훨씬 쉽습니다.

거기에

작은 로그

언급되지 않은 저장 프로 시저에 대한 또 하나의 작은 전문가 : SQL 트래픽과 관련하여 sp 기반 데이터 액세스는 훨씬 적은 트래픽을 생성 합니다. 이는 분석 및 프로파일 링을 위해 트래픽을 모니터링 할 때 중요합니다. 로그는 훨씬 작고 읽기 쉽습니다.

나는 저장 프로 시저를 좋아하지 않지만 한 가지 조건에서 사용합니다.

쿼리가 매우 크면 코드에서 보내는 대신 저장 프로 시저로 데이터베이스에 저장하는 것이 좋습니다. 이렇게하면 응용 프로그램 서버에서 데이터베이스로 방대한 양의 문자열 문자를 보내는 대신 "EXEC SPNAME"명령 만 전송됩니다.

데이터베이스 서버와 웹 서버가 동일한 네트워크 (예 : 인터넷 통신)에 있지 않으면 과도합니다. 그리고 그렇지 않은 경우에도 너무 많은 스트레스는 많은 낭비를 의미합니다.

그러나 사람들은 관리하기가 너무 끔찍합니다. 나는 가능한 한 많이 피한다.

SQL 저장 프로시 저는 쿼리 성능을 향상시키지 않습니다.

분명히 저장 프로 시저를 사용하면 코드에서 SQL을 구성하는 것보다 몇 가지 장점이 있습니다.

1. 코드 구현과 SQL은 서로 독립적이됩니다.
2. 코드를 읽기가 더 쉽습니다.
3. 한 번 사용하면 여러 번 쓸 수 있습니다.
4. 한 번 수정
5. 데이터베이스에 대해 프로그래머에게 내부 세부 사항을 제공 할 필요가 없습니다. 등

저장 프로 시저는 더 때문에 유지 보수 :

• SQL을 변경하려고 할 때마다 C # 앱을 다시 컴파일 할 필요가 없습니다.
• 결국 SQL 코드를 재사용하게됩니다.

유지 관리 가능한 응용 프로그램을 만들려고 할 때 코드 반복은 최악의 일입니다!

여러 곳에서 수정해야하는 논리 오류를 발견하면 어떻게됩니까? 코드를 복사하여 붙여 넣은 마지막 지점을 변경하는 것을 잊어 버릴 수 있습니다.

제 생각에는 성능 및 보안 이점이 더해집니다. 안전하지 않거나 비효율적 인 SQL 저장 프로 시저를 작성할 수 있습니다.

다른 DB로 쉽게 포팅 가능

다른 DB에서 작성하기 위해 모든 스토어드 프로 시저를 스크립팅하는 것은 그리 어렵지 않습니다. 실제로 걱정할 기본 / 외래 키가 없으므로 테이블을 내보내는 것보다 쉽습니다 .

@ Terrapin-sprocs는 주입 공격에 취약합니다. 내가 말했듯이:

항상 모든 쿼리를 매개 변수화하십시오-사용자 입력에서 어떤 것도 인라인하지 마십시오.

그것은 sprocs와 dynamic Sql에 적용됩니다.

앱을 다시 컴파일하지 않는 것이 유리하다는 확신이 없습니다. 내 말은, 당신은 어쨌든 다시 시작하기 전에 해당 코드 (응용 프로그램 및 DB 모두)에 대해 단위 테스트를 실행했습니다.

@Guy-그렇습니다 .sprocs는 응용 프로그램 사용자가 기본 작업이 아닌 sproc 만 수행 할 수 있도록 응용 프로그램 사용자를 제어 할 수있게합니다.

내 질문은 : 업데이트 및 삽입 권한이 제한된 사용자 및 연결을 사용하여 앱을 통해 액세스 할 경우이 추가 수준에 보안 또는 추가 관리가 추가됩니까?

제 의견은 후자입니다. 애플리케이션을 다시 작성할 수있는 수준으로 애플리케이션을 손상시킨 경우 사용할 수있는 다른 공격이 많이 있습니다.

동적으로 인라인 코드 인 경우 해당 sproc에 대해 SQL 삽입을 계속 수행 할 수 있으므로 골든 규칙이 여전히 적용되므로 모든 사용자 입력을 항상 매개 변수화해야합니다.

지금까지 내가 보지 못한 것 : 데이터베이스를 가장 잘 아는 사람들이 항상 응용 프로그램 코드를 작성하는 사람들은 아닙니다. 저장 프로시 저는 데이터베이스 사용자에게 SQL에 대해 배우고 싶지 않은 프로그래머와 인터페이스 할 수있는 방법을 제공합니다. 대형 데이터베이스, 특히 레거시 데이터베이스는 완전히 이해하기 가장 쉬운 방법이 아니므로 프로그래머는 필요한 인터페이스를 제공하는 간단한 인터페이스를 선호 할 수 있습니다.

그러나 저장 프로 시저 (PL / SQL은 악명 높은 예)를 작성하는 데 사용되는 언어는 매우 잔인합니다. 일반적으로 오늘날 인기있는 명령형, OOP 또는 기능적 언어에서 볼 수있는 멋진 기능은 제공하지 않습니다. 코볼을 생각하십시오.

따라서 비즈니스 로직을 포함하는 것이 아니라 관계형 세부 사항 만 추상화하는 저장 프로 시저를 고수하십시오.

나는 일반적으로 OO 코드를 작성합니다. 아마 대부분의 사람들도 그렇게 생각합니다. 그런 맥락에서 SQL 쿼리를 포함한 모든 비즈니스 로직이 클래스 정의에 속한다는 것이 분명합니다. 논리를 분할하여 일부가 오브젝트 모델에 있고 일부가 데이터베이스에 있도록하는 것은 비즈니스 논리를 사용자 인터페이스에 배치하는 것보다 낫지 않습니다.

저장된 procs의 보안 이점에 대해서는 이전 답변에서 많이 언급되었습니다. 이들은 크게 두 가지 범주로 나뉩니다.

1) 데이터에 대한 직접 액세스 제한. 이것은 어떤 경우에는 분명히 중요하며, 하나가 발생하면 저장된 procs가 유일한 옵션입니다. 내 경험상, 그러한 경우는 규칙이 아니라 예외입니다.

2) SQL 주입 / 매개 변수화 된 쿼리. 이 반대는 붉은 청어입니다. 동적으로 생성 된 인라인 SQL 인 경우에도 인라인 SQL은 저장된 모든 프로 시저와 마찬가지로 완전히 매개 변수화 할 수 있으며 염려 할만한 현대 언어로 쉽게 수행 할 수 있습니다. 여기서 어느 쪽의 장점도 없습니다. "게으른 개발자는 매개 변수를 사용하여 귀찮게하지 않을 수 있습니다"는 올바른 이의 제기가 아닙니다. 팀에서 사용자 데이터를 매개 변수를 사용하는 대신 SQL에 연결하는 것을 선호하는 개발자가있는 경우 먼저 교육을 시도한 다음 해고합니다. 그것이 효과가 없다면, 다른 나쁜, 명백하게 해로운 습관을 가진 개발자와 마찬가지로.)

나는 SPROC에 대한 거대한 코드 후원자입니다. 첫 번째 이유는 코드를 단단히 결합한 것이므로 두 번째로 사용자 정의 유틸리티를 많이 가져 오지 않고도 소스를 쉽게 제어 할 수 있습니다.

매우 복잡한 SQL 문이 있으면 DAL에서 일반적으로 리소스 파일로 포함하고 필요에 따라 업데이트합니다 (이것은 별도의 어셈블리 일 수도 있고 db별로 스왑 아웃 될 수 있습니다 ...).

이렇게하면 업데이트를 위해 외부 응용 프로그램을 실행하는 것을 잊어 버리지 않고 코드와 SQL 호출을 동일한 버전 컨트롤에 저장합니다.