0
여러 개의 서로 다른 쿼리를 포함하거나 모델에서 직접 개별적으로 모두 호출하는 저장 프로 시저 호출을 사용하여 뷰에서 데이터를 페치 할 수있는 MVC 응용 프로그램을 개발 중입니다. 어떤 접근 방식이 좋은 연습을하는지 혼란 스럽습니다. 나는 거의 모든 경우에 저장 프로 시저에 대한 단일 호출에 갈 것단일 저장 프로 시저 호출 또는 다중 데이터베이스 호출?
감사
A
답변
1
은 (내가 마지막에 예외 말 것).
이유 :
- 몇 가지 추가 논리를 도입 할 수 저장 프로 시저를 유지 누구든지 당신이이 중 하나를 자신의 직접 호출에 복제, 또는 것 (성능상의 이유로 또는 비즈니스 이유를 수) -도 악화 - 스토어드 프로 시저를 유지 관리하는 사람과의 의사 소통 불량으로 인해 모두 누락 될 수 있습니다. (둘 다 유지하더라도 복제에 많은 노력을 기울여야합니다.) # 1 이유 : 전용 인터페이스를 사용하여 정확성 보장 및 중복 방지
- DB와 상호 작용할 때마다 연결을 열거 나 풀에서 검색 할 때 오버 헤드가 아닌 작은 오버 헤드가 발생합니다. 네트워크상의 데이터 마샬링 및 언 마샬링, 네트워크 대기 시간 등이 포함됩니다. 단일 진입 점 (저장 프로 시저)을 사용하면 이러한 점을 상쇄 할 수 있습니다.
- DB 엔진이 단일 트랜잭션 컨텍스트에서 모든 작업을 수행하여 작업 부하를 최적화 할 수 있다는 것은 가능하지만 (실제로는 많은 요소에 따라 다르므로 아무 것도 보장하지는 않습니다) 나는. 어쩌면 인덱스/레코드 중 일부가 DB 캐시에 버퍼링되어 두 번째 쿼리에서 더 빨리 액세스 할 수있는 것과 유사한 두 개의 연속 쿼리를 발행 할 수 있습니다.
가능한 예외 : 응용 프로그램에 멀티 코드 구조의 머리글을 먼저로드하고 사용자가 필요로하는 경우에만 하위 수준의 세부 정보가 필요한 일종의 "확대/축소"프로세스가 있습니다. 이 경우에는 즉시 액세스하는 것이 좋습니다. 세부 레코드가 프론트 엔드에서 부담이 될만큼 충분히 크다는 것을 증명할 수 없다면 (즉, 실제로드로 테스트 할 수 없다면) 이전 솔루션을 더 선호 할 것입니다. "통찰력"을 백업 할 하드 데이터가 없다면이 방법이 더 효율적이라고 결정하려는 유혹에 빠져보십시오. 대부분이 시간은 prove to be a mistake입니다.