[C#] 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 코드를 이들 중 하나에 넣을 수 있습니다. 또는 첨단 기술을 원한다면이를위한 라이브러리를 사용할 수 있습니다. 나는 그것들이 객체 관계형 매퍼라고 불리우며 요즘 꽤 일반적입니다.

a

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

저장 프로 시저가 나쁜 이유입니다. 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입니다. 테이블 스키마가 올바른지 확인하면되므로 데이터베이스 배포가 간단 해집니다. 소스 코드와 데이터베이스를 볼 필요가 없으므로 코드 유지 관리가 간소화됩니다.

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


댓글 달기

이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다