내가 SELECT 쿼리에서 데이터를 반환하는 저장 프로 시저가 있다고 가정 해보십시오. 내가 통과 한 매개 변수에 따라 결과에 약간 다른 상처를주고 싶습니다. GetXByDate 또는 GetXByUser 같은 작업을 수행하는 매개 변수가 하나 또는없는 다중 저장 프로 시저가 있거나 더 많은 작업을 수행하는 여러 매개 변수 (예 : GetX)가있는 저장 프로 시저를 사용하는 것이 더 좋은 디자인인지 궁금합니다.더 적은 수의 매개 변수로보다 대상이 명확한 저장 프로 시저를 작성하는 것이 더 좋습니까?
첫 번째 옵션의 장점은 간단하고 빠를 수도 있지만 단점은 쿼리의 본질이 저장 프로 시저에 중복되어 여러 위치에서 유지되어야한다는 것입니다.
두 번째 옵션의 장점은 쿼리가 한 번만 나타나지만 쿼리가 더 복잡하고 문제 해결이 어려워지는 단점입니다.
솔루션에서 무엇을 사용하며 그 이유는 무엇입니까?
더 복잡한 저장 프로 시저가 더 복잡하다.
큰 저장 프로 시저에서조차도 쿼리의 사본을 여러 개 가지거나 성능을 떨어 뜨리는 많은 CASE 및 IF를 추가해야합니다. 그래서 당신은 모든 것을 함께 묶는 데별로 도움이되지 않습니다.
개인적인 경험으로 볼 때, 여러 개의 작고 직선적 인 sprocs를 관리하기가 더 어려울 정도로 많은 SQL sp 코드를 고려합니다.
쿼리 코드의 복사 붙여 넣기를 줄이기 위해 뷰와 UDF를 사용할 수 있습니다.
퍼포먼스에 대해 신경 쓰지 않는다면 (인트라넷 앱은 쿼리가 너무 무겁지 않으므로 자주 실행하지 않아야합니다) 유니버설 sproc을 사용하면 매우 편리하다는 것을 알 수 있습니다.
누가 이러한 저장 프로 시저를 호출 할 것입니까? 나는 SELECT 문에 대한 저장 프로 시저를 일반적으로 작성하지 않을 것이다. 왜냐하면 다른 테이블에 조인을 포함하여 원하는 SELECT 문이 많이 있기 때문이다.
나는 간단한 저장 프로 시저의 경우 GetXByDate, GetXByUser, 어쨌든 약간의 유지 보수가 필요하기 때문에 복잡한 코드보다 중복 된 코드를 유지하는 것이 더 쉽다고 생각합니다.
물론 복잡한 저장 프로 시저가있는 경우에는 그렇지 않을 수 있습니다. GetAndProcessXByDate는 GetXByDate, GetXByUser 등으로 더 잘 축소 될 수 있습니다 ... 다른 저장된 proc ProcessX를 호출합니다.
는 그래서 확실한 대답은 추측 : 그것은 의존한다 ... :)이 SQL 서버가 제대로 를 컴파일하고 신속하고 효율적으로 실행하기 위해클래스의 메서드와 동일한 방식으로 저장 프로 시저를 처리합니다. 그것은 한 가지 일을하고 간단하게해야합니다. 동일한 종류의 리팩토링/코드 냄새 규칙을 응용 프로그램 코드에서 사용할 저장 프로 시저에 적용하는 것이 좋습니다.
LinqToSQL과 같이 생성 된 C# 데이터 액세스 레이어를 사용하는 경우 단일 저장 프로 시저의 장점 중 하나는 결과 집합을 나타내는 단일 클래스가 생성됩니다.
두 번째 @tvanfosson.
그러나 나는 둘 다 할 수 있다고 덧붙였다 : 다중 사용 sproc (예.GetX)를 사용하여 쿼리의 전체 클래스에 필수 로직을 포함하고 적절한 매개 변수를 전달하여 큰 sprocs (GetXY, GetXZ)를 반복 실행합니다.
이것은 자신을 반복하지 않는다는 것을 의미하지만 클라이언트 응용 프로그램에 간단한 인터페이스를 제공 할 수도 있습니다. GetXY에 대해서 알아야 할 필요가없는 응용 프로그램 만 GetXZ에 대해 알 필요가 없습니다.
가끔이 접근 방식을 사용합니다.
AJ 접근 방식을 사용하면 두 가지 장점을 모두 누릴 수 있습니다. 여러 sprocs에 걸쳐 반복 된 코드를 유지해야하는 고통은 과장 될 수 없습니다.
일반적인 용도로 Sproc 및 UDF 모듈을 빌드하고 작업 별 sprocs에서 호출하십시오.
감사합니다 .-- 분명히 당신은 매우 지각있는 개인입니다. –