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

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

저장 프로시 저는 다음과 같은 이유로 유지 관리가 더 용이합니다. * 일부 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 백만 달러의 비용이 드는지 정당화하려는 경우 모든 것을 백만 계층 으로 나누는 것이 합리적 일 수 있습니다. 이익.

답변

(Pseudocode)

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