SQL을 Stored Procs와 Code로 유지하는 장단점은 무엇입니까?

SQL을 Stored Procs와 Code로 유지하는 장단점은 무엇입니까?

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

닫힘9년 전.

잠겼습니다. 이 질문과 답변은이 질문은 부적절하지만 역사적 의미가 있기 때문에 잠겨 있습니다.현재 새로운 답변이나 상호작용을 받아들이지 않고 있습니다.

SQL을 C# 소스 코드 또는 Stored Procs에 보관하는 것의 장점과 단점은 무엇입니까?현재 진행 중인 오픈 소스 프로젝트(C# ASP)에서 친구와 이 문제에 대해 논의했습니다.NET 포럼).현재 대부분의 데이터베이스 액세스는 C#에 SQL을 인라인으로 구축하여 SQL Server DB에 호출함으로써 이루어집니다.그래서 저는 이 프로젝트에 어떤 것이 가장 좋은지 알아내려고 합니다.

지금까지의 내용:

코드 내 장점:

• 유지보수가 용이함 - 쿼리를 업데이트하기 위해 SQL 스크립트를 실행할 필요가 없음
• 다른 DB로의 포팅이 용이함 - 프로세서를 포트로 사용하지 않음

저장된 Proc의 이점:

• 성능
• 보안.

저장 프로시저를 좋아하지 않습니다.

스토어드 프로시저는 다음과 같은 이유로 유지보수가 용이합니다.* 일부 SQL을 변경할 때마다 C# 앱을 다시 컴파일할 필요가 없습니다.

데이터 유형이 변경되거나 추가 열을 반환할 경우 다시 컴파일할 수 있습니다.앱 아래에서 SQL을 '투과적으로' 변경할 수 있는 횟수는 전체적으로 매우 적습니다.

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

C#을 포함한 프로그래밍 언어에는 함수라는 놀라운 기능이 있습니다.즉, 여러 장소에서 동일한 코드 블록을 호출할 수 있습니다.최고야!그런 다음 재사용 가능한 SQL 코드를 이들 중 하나에 넣을 수 있습니다. 또는 매우 고도의 기술을 얻고 싶다면 라이브러리를 사용할 수 있습니다.오브젝트 릴레이셔널 맵퍼라고 불리며, 요즘은 꽤 흔합니다.

유지보수가 가능한 애플리케이션을 구축하려고 할 때 코드 반복은 최악의 작업입니다.

동의해, 그래서 스토어드 프로세서가 나쁜 거야SQL보다 (작은 부분으로 분할된) 코드를 함수로 재팩터링하고 분해하는 것이 훨씬 쉽습니다.SQL 블록?

4대의 웹 서버와 동일한 SQL 코드를 사용하는 다수의 윈도 앱이 있습니다.SQL 코드에 작은 문제가 있음을 알게 되었습니다.그러면...프로세서를 한 곳에서 변경하거나 코드를 모든 웹 서버에 푸시하거나 모든 윈도 박스에 데스크톱 앱을 다시 설치합니다(클릭하면 도움이 될 수 있습니다.

Windows 어플리케이션이 중앙 데이터베이스에 직접 접속되는 이유는 무엇입니까?이는 커다란 보안 취약점처럼 보이며 서버 측 캐싱을 배제하기 때문에 병목현상이 발생합니다.웹 서비스를 통해 연결하거나 웹 서버와 유사해야 하지 않습니까?

새로운 spro를 1대, 아니면 웹 서버를 4대?

이 경우 새로운 spro를 푸시하는 것이 더 쉽지만, 제 경험상 '푸시 변경'의 95%는 데이터베이스가 아닌 코드에 영향을 미칩니다.그 달에 웹 서버에 20개를 푸시하고 데이터베이스에 1개를 푸시하는 경우 웹 서버에 21개를 푸시하고 데이터베이스에 0개를 푸시하는 경우 큰 손실은 없습니다.

코드 검토가 용이함.

어떻게 하는지 설명해 주시겠어요?이거 안 사.특히 sprocs는 소스 제어 상태가 아니므로 웹 기반 SCM 브라우저 등을 통해 액세스할 수 없습니다.

기타 단점:

Storedprocs는 데이터베이스에 존재하며, 외부에서는 블랙박스로 표시됩니다.소스 컨트롤에 넣고 싶은 간단한 일들은 악몽이 됩니다.

순수한 노력의 문제도 있습니다.CEO에게 포럼을 구축하는 데 700만 달러밖에 들지 않은 이유를 설명하려고 한다면 모든 것을 100만 개의 계층으로 세분화하는 것이 타당할 수 있지만, 그렇지 않으면 작은 일마다 스토어드프로세서를 작성하는 것은 전혀 도움이 되지 않는 추가 작업일 뿐입니다.

이는 현재 몇 가지 다른 스레드에서 논의되고 있습니다.저는 스토어드 프로시저의 일관된 지지자이지만, Linq to SQL에 대한 몇 가지 좋은 논거가 제시되고 있습니다.

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

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

[편집] 현재 진행 중인 또 다른 토의입니다.

내 생각에 당신은 이 문제에 대해 찬반 투표를 할 수 없다.어플리케이션 디자인에 따라 달라집니다.

애플리케이션 서버가 있는 3계층 환경에서 SP를 사용하는 것은 전적으로 반대합니다.이러한 환경에서는 애플리케이션 서버가 비즈니스 로직을 실행할 수 있습니다.SP를 추가로 사용하면 시스템 전체에 비즈니스 로직 구현을 배포하기 시작합니다. 그러면 누가 무엇을 담당하는지 매우 불명확해집니다.최종적으로는 다음과 같은 작업밖에 하지 않는 애플리케이션 서버를 사용하게 됩니다.

(Pseudocode)

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

최종적으로는 이 매우 쿨한4개의 서버 클러스터 상에서 중간 계층이 가동되게 됩니다.각 클러스터에는 16개의 CPU가 탑재되어 있기 때문에 실제로는 아무것도 동작하지 않습니다.아깝다!

DB에 직접 연결하는 대용량 GUI 클라이언트나 더 많은 애플리케이션을 사용하는 경우에는 상황이 달라집니다.이 경우 SP는 애플리케이션을 데이터 모델에서 분리하여 제어 가능한 액세스를 제공하는 일종의 의사 중간 계층 역할을 할 수 있습니다.

코드 내 장점:

• 유지보수가 용이함 - 쿼리를 업데이트하기 위해 SQL 스크립트를 실행할 필요가 없음
• 다른 DB로의 포팅이 용이함 - 프로세서를 포트로 사용하지 않음

사실, 내 생각에 넌 그걸 거꾸로 알고 있는 것 같아.IMHO, 코드의 SQL은 다음과 같은 이유로 유지보수가 어렵습니다.

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

Stored Procs는 데이터베이스 오브젝트에서 호출하는 메서드라고 생각하시면 됩니다.이 메서드는 재사용이 훨씬 쉽고 편집 장소가1개밖에 없습니다.DB 프로바이더를 변경할 경우 변경은 코드가 아닌 Stored Procs에서 이루어집니다.

즉, Stu가 전에 말한 바와 같이 Storeed Proc의 성능 향상은 미미하며 Storeed Procedure에 중단점을 둘 수는 없습니다.

결점

스토어드 프로시저 내에서 많은 처리를 하면 DB 서버의 유연성이 저하됩니다.

그러나 sql-server가 아닌 프로그램에서 이러한 모든 처리를 수행하면 코드를 실행하는 서버가 여러 개 있는 경우 확장성이 향상될 수 있습니다.물론 이는 일반 가져오기 또는 업데이트만 하는 저장된 프로세서에는 적용되지 않지만 데이터셋을 통한 루프와 같이 더 많은 처리를 수행하는 프로세서에는 적용됩니다.

장점

1. 가치 있는 퍼포먼스(DB 드라이버/플랜 레크리에이션 등에 의한 쿼리 해석 불필요)
2. 데이터 조작은 C/C++/C# 코드에 포함되어 있지 않습니다.그 때문에, 보다 낮은 레벨의 코드를 조사할 필요가 없습니다.SQL은 별도로 나열하면 상세하고 자세히 살펴보기 쉽습니다.
3. 이러한 분리를 통해 SQL 코드를 훨씬 쉽게 찾아 재사용할 수 있습니다.
4. 스키마가 변경되면 변경하기 쉬워집니다.코드에 같은 출력을 주면 정상적으로 동작합니다.
5. 다른 데이터베이스로의 포팅이 용이합니다.
6. 저장 프로시저에 대한 개별 권한을 나열하고 해당 수준에서 액세스를 제어할 수 있습니다.
7. 데이터 변환 코드와 별도로 데이터 쿼리/지속성 코드를 프로파일링할 수 있습니다.
8. 스토어드 프로시저에서 변경 가능한 조건을 구현할 수 있어 고객 사이트에서 쉽게 커스터마이즈할 수 있습니다.
9. 스키마와 스테이트먼트가 코드에 포함되어 있는 경우보다 자동화된 툴을 사용하여 함께 변환하는 것이 쉬워집니다.
10. 데이터 액세스의 베스트 프랙티스는, 모든 데이터 액세스 코드가 1개의 파일내에 있는 경우, 보다 간단하게 실시할 수 있습니다.비퍼포먼스 테이블에 액세스 하는 쿼리, 또는 보다 높은 레벨의 시리얼라이제이션이 사용되고 있는 쿼리를 체크하거나, 코드의 * 를 선택할 수 있습니다.
11. 스키마 변경/데이터 조작 로직 변경은 모두 한 파일에 나열하면 쉽게 찾을 수 있습니다.
12. SQL이 동일한 위치에 있을 경우, 예를 들어 저장된 모든 프로세서에 대한 트랜잭션 분리 문 변경/추가 등 SQL에서 편집 및 치환을 보다 쉽게 수행할 수 있습니다.
13. 저와 DBA 담당자는 DBA가 제 SQL 자료를 검토해야 할 때 별도의 SQL 파일을 갖는 것이 더 쉽고 편리하다는 것을 알게 되었습니다.
14. 마지막으로 임베디드 SQL을 사용할 때 일부 게으른 팀원이 매개 변수화된 쿼리를 사용하지 않았기 때문에 SQL 주입 공격에 대해 걱정할 필요가 없습니다.

저장 프로시저의 성능상의 이점은 무시할 수 있는 경우가 많습니다.

저장 프로시저의 다른 이점:

• 리버스 엔지니어링 방지(물론 암호화로 작성된 경우)
• 데이터베이스 접근 집중화 향상
• 새로운 클라이언트를 도입하지 않고 데이터 모델을 투과적으로 변경할 수 있습니다.여러 프로그램이 같은 데이터 모델에 액세스 할 경우 특히 편리합니다.

나는 코드 쪽에 넘어졌다.델은 모든 애플리케이션(웹 및 클라이언트)에서 사용하는 데이터 액세스 레이어를 구축하기 때문에 이러한 관점에서 DRY라고 할 수 있습니다.테이블 스키마가 올바른지 확인하기만 하면 되기 때문에 데이터베이스 도입이 간단해집니다.소스 코드와 데이터베이스를 볼 필요가 없기 때문에 코드 유지보수가 간단해집니다.

데이터 모델과의 긴밀한 결합에는 큰 문제가 없습니다.왜냐하면 실제로 결합을 끊을 수 있는 부분이 어디인지 알 수 없기 때문입니다.애플리케이션과 그 데이터는 본질적으로 결합되어 있다.

저장 프로시저

오류가 발생하거나 논리가 약간 변경된 경우 프로젝트를 다시 컴파일할 필요가 없습니다.또한 프로젝트에서 쿼리를 코드화한 위치뿐만 아니라 다른 소스에서도 액세스할 수 있습니다.

스토어드 프로시저를 유지하는 것이 더 어렵다고 생각하지 않습니다.데이터베이스에서 직접 코드화하지 말고 별도의 파일로 먼저 코드화한 다음 셋업할 DB에서 실행할 수 있습니다.

저장 프로시저의 장점:

코드 검토가 용이함.

결합이 적기 때문에 테스트가 용이합니다.

보다 쉽게 튜닝할 수 있습니다.

네트워크 트래픽의 관점에서는 일반적으로 퍼포먼스가 향상됩니다.커서 등이 있으면 데이터베이스로의 이행이 여러 번 이루어지지 않습니다.

데이터에 대한 접근을 보다 쉽게 보호하고, 테이블에 대한 직접 접근을 삭제하며, Proc를 통한 보안을 강화할 수 있습니다.또한 테이블을 갱신하는 모든 코드를 비교적 빠르게 검색할 수 있습니다.

관련된 다른 서비스(리포트 서비스 등)가 있는 경우 모든 로직을 코드가 아닌 스토어드 프로시저에 저장하여 복제하는 것이 더 쉬울 수 있습니다.

단점:

개발자가 관리하기 어려운 스크립트 버전 관리: 모든 사용자가 자신의 데이터베이스를 가지고 있는지, 버전 관리 시스템이 데이터베이스 및 IDE와 통합되어 있는지 여부

경우에 따라서는 코드에서 동적으로 생성된 sql이 저장된 proc보다 더 나은 성능을 가질 수 있습니다.stored proc(sp_customersearch 등)를 작성하면 유연성이 매우 높아지기 때문에 수십 개의 파라미터가 매우 복잡해지면 실행 시 코드로 훨씬 심플한 sql 문을 생성할 수 있습니다.

이는 단순히 SQL에서 웹 서버로 일부 처리를 이동시킬 뿐이지만, 일반적으로는 좋은 일이라고 할 수 있습니다.

이 기술의 또 다른 장점은 SQL 프로파일러에서 생성한 쿼리를 확인할 수 있고 20개의 파라미터를 가진 저장된 proc 호출이 들어오는 것보다 훨씬 쉽게 디버깅할 수 있다는 것입니다.

스토어드·프로세서가 마음에 드는데, 스토어드·프로시저를 사용해 애플리케이션을 몇번이나 변경할 수 있었는지, 애플리케이션의 다운타임이 발생하지 않았습니다.

Transact SQL의 열렬한 팬인 대규모 쿼리 조정은 저에게 매우 유용한 것으로 입증되었습니다.약 6년 동안 인라인 SQL을 작성하지 않았습니다.

sprocs의 프로포인트는 2가지입니다.

퍼포먼스 - 별로.SQL 2000 이상에서는 쿼리 계획의 최적화가 매우 양호하고 캐시되어 있습니다.Oracle 등도 비슷한 일을 하고 있을 것입니다.더 이상 퍼포먼스에 대한 sprocs의 케이스는 없다고 생각합니다.

보안?왜 스프로크가 더 안전할까요?보안이 엄격한 데이터베이스가 없는 한 모든 액세스는 DBA 또는 애플리케이션을 통해 이루어집니다.항상 모든 쿼리를 매개 변수화하십시오. 사용자 입력에서 인라인화하지 마십시오. 그러면 문제가 없습니다.

어쨌든 퍼포먼스를 위한 베스트 프랙티스입니다.

린크는 확실히 지금 새로운 프로젝트를 진행하고 있는 사람입니다.같은 투고를 참조해 주세요.

@키스

보안?왜 스프로크가 더 안전할까요?

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

(물론 sprocs를 실행하면 필요한 모든 데이터가 제공되지만 이는 사용 가능한 sproc에 따라 달라집니다.테이블에 액세스 할 수 있게 되면, 모든 것에 액세스 할 수 있게 됩니다.)

이렇게 생각해 보세요

4대의 웹 서버와 동일한 SQL 코드를 사용하는 다수의 윈도 앱이 있습니다.SQL 코드에 작은 문제가 있음을 알게 되었습니다.그러면...프로세서를 한 곳에서 변경하거나 코드를 모든 웹 서버에 푸시하거나 모든 윈도 박스에 데스크톱 앱을 다시 설치합니다(클릭하면 도움이 될 수 있습니다.

저장된 프로세서를 선호합니다.

또한 set showplan_text on 및 voila의 쿼리 아나라이저 set statistics io/time에 프로세서에 대한 퍼포먼스 테스트도 간단합니다.

호출된 대상을 정확하게 확인하기 위해 프로파일러를 실행할 필요가 없습니다.

내 2센트만

.sql 파일을 저장할 필요 없이 소스 컨트롤의 대상이 되도록 코드(인라인이나 애드혹이 아닌 ORM 사용)로 유지하는 것이 좋습니다.

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

앱 코드를 최적의 기능인 로직 처리로 사용합니다.
최적의 기능인 데이터 저장에 맞게 데이터베이스를 사용자 지정합니다.

스토어드 프로시저를 디버깅할 수 있지만 코드 내의 로직 디버깅 및 유지보수가 쉬워집니다.일반적으로 데이터베이스 모델을 변경할 때마다 코드 재컴파일이 종료됩니다.

또한 가능한 모든 파라미터를 미리 지정해야 하고 검색에서 파라미터가 반복될 횟수를 예측할 수 없기 때문에 검색 파라미터가 옵션인 스토어드 프로시저는 매우 번거롭습니다.

보안에 관해서는 스토어드 프로시저가 훨씬 안전합니다.어떤 사람들은 모든 접근은 어쨌든 애플리케이션을 통해 이루어질 것이라고 주장해왔다.많은 사람들이 잊고 있는 것은 대부분의 보안 침해는 회사 내부에서 발생한다는 것입니다.애플리케이션의 "숨겨진" 사용자 이름과 암호를 알고 있는 개발자가 얼마나 됩니까?

또한 MatthieuF가 지적한 바와 같이 애플리케이션(데스크탑 서버 또는 웹 서버)과 데이터베이스 서버 간의 왕복이 적기 때문에 성능이 크게 향상될 수 있습니다.

제 경험상 스토어드 프로시저를 통한 데이터 모델의 추상화도 유지보수의 용이성을 크게 향상시켰습니다.지금까지 많은 데이터베이스를 유지 보수해야 했던 사용자로서 필요한 모델 변경에 직면했을 때 저장 프로시저를 한두 개만 변경할 수 있고 변경 내용이 모든 외부 애플리케이션에 대해 완전히 투명해질 수 있다는 것은 매우 안심할 수 있습니다.대부분의 경우 어플리케이션만이 데이터베이스를 가리키는 것이 아닙니다.다른 어플리케이션이나 보고서 솔루션 등이 있기 때문에 테이블에 대한 오픈액세스로 인해 영향을 받는 포인트를 모두 추적하는 것이 번거로울 수 있습니다.

또한 SQL 프로그래밍을 전문으로 하는 사람들이 사용할 수 있도록 하기 위해, SP가 코드를 훨씬 쉽게 분리 및 테스트/최적화할 수 있도록 하기 위해 더하기 열에 체크 표시를 합니다.

한 가지 단점은 많은 언어가 테이블 파라미터의 전달을 허용하지 않기 때문에 알 수 없는 수의 데이터 값을 전달하는 것은 번거로울 수 있으며 일부 언어는 여전히 단일 저장 프로시저에서 여러 결과 세트를 검색할 수 없다는 것입니다(단, SP가 인라인 SQL보다 더 나쁜 것은 아닙니다).

내가 참석한 Microsoft TechEd 세션에서 제안한 보안에 관한 제안 중 하나는 저장된 프로세서를 통해 모든 콜을 발신하고 테이블에 대한 직접 접근을 거부하라는 것입니다.이 접근방식은 보안을 강화하는 것으로 알려져 있습니다.보안상 가치가 있는지는 모르겠지만 이미 저장된 프로세서를 사용하고 있다면 문제 없습니다.

저장 프로시저에 넣으면 확실히 유지보수가 쉬워집니다.향후 변경될 가능성이 있는 어려운 논리가 있는 경우에는 여러 클라이언트가 접속하고 있을 때 데이터베이스에 저장하는 것이 좋습니다.예를 들어, 현재 최종 사용자 웹 인터페이스와 관리 데스크톱 애플리케이션이 있는 애플리케이션을 작업하고 있으며, 이 두 애플리케이션은 데이터베이스를 공유하고 있으며, 가능한 한 많은 논리를 데이터베이스에 유지하려고 합니다.이것은 DRY 원리의 완벽한 예입니다.

저장된 proc에서 동적 SQL을 사용하지 않는 한 저장된 proc의 편에 서 있습니다.첫째, 저장된 proc를 사용하면 dba는 테이블 레벨이 아닌 저장된 proc 수준에서 권한을 설정할 수 있습니다.이는 SQL 주입 어태치와의 싸움뿐만 아니라 내부자가 데이터베이스에 직접 액세스하여 변경되는 것을 방지하기 위해 매우 중요합니다.이것은 사기를 예방하는 데 도움이 됩니다.개인정보(SSN, 신용카드 번호 등)를 포함하는 데이터베이스나 금융거래를 생성하는 데이터베이스는 스트로핑 절차를 거치지 않는 한 접근해서는 안 됩니다.다른 방법을 사용하면 사내 개인에게 가짜 금융 거래를 작성하거나 ID 도용에 사용할 수 있는 데이터를 훔칠 수 있도록 데이터베이스를 활짝 열어 둡니다.

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

현재 제가 근무하는 Oracle DB에서는 스토어드 프로시저를 사용하고 있습니다.Subversion도 사용합니다.저장 프로시저는 모두 .pkb 및 .pks 파일로 생성되어 Subversion에 저장됩니다.이전에 인라인 SQL을 실행한 적이 있는데, 매우 번거롭습니다.나는 우리가 여기서 하는 방식이 훨씬 더 좋다.새로운 저장 프로시저를 만들고 테스트하는 것은 코드로 하는 것보다 훨씬 쉽습니다.

테레사

작은 로그

스토어드 프로시저의 또 다른 마이너 프로시저는 SQL 트래픽의 경우 SP 기반 데이터 액세스로 생성되는 트래픽이 훨씬 적다는 것입니다.이는 분석 및 프로파일링을 위해 트래픽을 모니터할 때 중요합니다. 로그는 훨씬 작고 읽을 수 있습니다.

스토어드 프로시저는 그다지 좋아하지 않지만 다음 한 가지 조건으로 사용합니다.

쿼리가 매우 큰 경우 코드에서 보내는 것이 아니라 저장 프로시저로 데이터베이스에 저장하는 것이 좋습니다. 응용 하는 것이 「」만 됩니다."EXEC SPNAME"명령어가 전송됩니다.

데이터베이스 서버와 웹 서버가 같은 네트워크상에 없는 경우(예를 들어 인터넷 통신)에는, 과잉입니다.그게 아니더라도 스트레스가 너무 많으면 밴드와의 관계가 많이 낭비되는 거야

하지만 정말 감당하기 힘들죠나는 가능한 한 그들을 피한다.

SQL 스토어드 proc는 쿼리의 성능을 향상시키지 않습니다.

스토어드 프로시저를 사용하면 SQL을 코드로 구성하는 것보다 몇 가지 이점이 있습니다.

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

저장 프로시저는 다음과 같은 이유로 유지보수가 용이합니다.

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

유지보수가 가능한 애플리케이션을 구축하려고 할 때 코드 반복은 최악의 작업입니다.

여러 곳에서 수정이 필요한 논리 오류를 발견하면 어떻게 됩니까?코드를 복사하여 붙여넣는 마지막 위치를 변경하는 것을 잊기 쉽습니다.

퍼포먼스와 보안의 향상은 플러스라고 생각합니다.여전히 안전하지 않거나 비효율적인 SQL 저장 프로시저를 쓸 수 있습니다.

다른 DB로의 포팅이 용이함 - 프로세서를 포트로 사용하지 않음

다른 DB에 생성하기 위해 모든 저장 프로시저를 스크립팅하는 것은 그리 어렵지 않습니다.실제로 테이블을 내보내는 것보다 더 쉽습니다.기본 키나 외부 키를 걱정할 필요가 없기 때문입니다.

@Terrapin - sprocs는 주입 공격에 취약합니다.말씀드렸듯이

항상 모든 쿼리를 매개 변수화하십시오. 사용자 입력에서 인라인화하지 마십시오. 그러면 문제가 없습니다.

이는 sprocs 및 동적 SQL에도 해당됩니다.

앱을 다시 컴파일하지 않는 것이 장점인지 잘 모르겠습니다.즉, 다시 가동하기 전에 해당 코드(애플리케이션과 DB 모두)에 대해 유닛 테스트를 실행한 것입니다.

---

@Guy - 네, 맞습니다.스프록에서는 어플리케이션 사용자를 제어할 수 있기 때문에 사용자는 기본 액션이 아닌 sproc만 실행할 수 있습니다.

질문입니다. 모든 액세스가 앱을 통해 액세스하고 연결 및 업데이트/삽입 권한이 제한된 사용자를 사용하는 경우 이 추가 수준이 보안을 추가합니까? 아니면 관리를 추가합니까?

내 의견은 거의 후자다.애플리케이션을 재작성할 수 있을 정도로 손상시킨 경우, 그 밖에도 많은 공격을 할 수 있습니다.

sprocs가 동적으로 인라인 코드인 경우 sprocs에 대해 SQL 주입을 계속 수행할 수 있습니다.따라서 골든 규칙이 적용되므로 모든 사용자 입력은 항상 파라미터화되어야 합니다.

지금까지 본 적이 없는 것:데이터베이스를 가장 잘 아는 사람이 항상 애플리케이션 코드를 작성하는 사람은 아닙니다.스토어드 프로시저는 SQL에 대해 별로 배우고 싶지 않은 프로그래머와 데이터베이스 담당자와 인터페이스할 수 있는 방법을 제공합니다.대규모 데이터베이스, 특히 레거시 데이터베이스는 완전히 이해하기 쉬운 것은 아닙니다.따라서 프로그래머는 필요한 것을 제공하는 단순한 인터페이스를 선호할 수 있습니다. DBA가 이를 실현하기 위해 17개의 테이블을 결합하는 방법을 파악하도록 합니다.

그러나 스토어드 프로시저를 작성하는 데 사용되는 언어(PL/SQL은 악명 높은 예)는 매우 잔인합니다.일반적으로 오늘날 널리 사용되는 명령어, OOP 또는 기능 언어에서 볼 수 있는 세세한 부분까지 모두 제공하지 않습니다.COBOL을 생각해 보세요.

따라서 비즈니스 로직을 포함하는 저장 프로시저가 아니라 관계 세부 정보를 추상화하는 저장 프로시저를 고수하십시오.

저는 일반적으로 OO코드를 씁니다.아마 여러분들도 그럴 거라고 생각합니다.이러한 맥락에서 SQL 쿼리를 포함한 모든 비즈니스 로직이 클래스 정의에 속한다는 것은 명백합니다.로직의 일부가 오브젝트 모델에 존재하고 일부가 데이터베이스에 존재하도록 로직을 분할하는 것은 비즈니스 로직을 사용자 인터페이스에 넣는 것과 다를 바 없습니다.

이전 답변에서는 저장된 프로세서의 보안상의 이점에 대해 많은 것이 언급되어 왔습니다.이는 크게 두 가지 범주로 나뉩니다.

1) 데이터에 대한 직접 접근 제한이것은 매우 중요한 경우도 있습니다.또한 이 문제가 발생했을 때는 저장 프로가 거의 유일한 옵션입니다.그러나 내 경험상 그러한 경우는 규칙이라기보다 예외이다.

2) SQL 주입/파라미터화된 쿼리.이 반대는 속임수다.인라인 SQL - 동적으로 생성된 인라인 SQL도 저장된 proc와 마찬가지로 완전히 파라미터화 할 수 있습니다.또한 가치가 있는 최신 언어에서도 마찬가지로 쉽게 할 수 있습니다.어느 쪽이든 이 점에서는 이점이 없습니다.("Lazy Developer는 파라미터를 사용하는 데 신경 쓰지 않을 수 있습니다."는 타당한 반대 의견은 아닙니다.파라미터가 아닌 SQL에 사용자 데이터를 연결하는 것을 선호하는 개발자가 있는 경우, 먼저 교육하고, 그것이 효과가 없을 경우 해고합니다.다른 나쁜 습관이 있는 개발자에게도 마찬가지입니다.)

나는 SPROC보다 코드를 더 많이 지지한다.첫 번째 이유는 코드를 긴밀하게 결합시키는 것입니다.다음으로는 코드를 풀할 수 있는 커스텀 유틸리티가 많지 않아도 소스 제어가 용이하다는 점입니다.

매우 복잡한 SQL 문이 있는 경우 일반적으로 리소스 파일로 포함시키고 필요에 따라 업데이트합니다(이것도 별도의 어셈블리가 될 수 있으며 DB별로 스왑 아웃됨 등).

이를 통해 코드와 SQL 호출이 동일한 버전 제어에 저장되므로 업데이트를 위해 외부 응용 프로그램을 실행하는 것을 "잊지" 않습니다.

언급URL : https://stackoverflow.com/questions/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code