복잡한 쿼리 또는 저장 프로 시저를 작성한 후 결과가 100 % 정확하다는 것을 어떻게 확인하고 모든 입력 매개 변수에 적용되는지 확인하십시오.쿼리 결과 확인
내 개인적인 접근 방식은 개발을 통해 테스트, 테스트 및 테스트하는 것입니다. 예상하지 못하는 곳에 NULL이 나타나지 않고 행이 떨어지거나 두배로 늘어나지 않는다는 것을 확인합니다. 쿼리를 완료했습니다. 결과 집합에서 임의의 레코드를 가져 와서 테스트의 '양'을 수행 한 다음 이들이 예상대로 있는지 확인합니다.
복잡한 쿼리를 작성할 때 나는 항상 원하는 모든 입력 집합에 대한 예상 결과를 작성합니다. 데이터 세트를 추출하고 입력을 기반으로 결과 행렬을 컴파일하십시오. 복잡한 쿼리를 작성하기 시작할 때 초기 테스트 매트릭스를 기반으로 각 쿼리가 정확한 결과를 생성하는지 확인할 수 있습니다.
필자는 필터링/결과 조건의 각 특정 사례가 충족 될 수 있도록 데이터를 매우 간단하고 최소한으로 유지하는 경향이 있습니다. SQL 자체가 매우 복잡하더라도 설계 및 구현 중에 유효성 검증을 위해 결과를 정량화하는 것은 혼란스럽고 복잡하며 인식하지 못하면 잘못된 결과를 초래할 수 있습니다. 한 번만 샘플 데이터에 대해 100 % 확신 할 때만 프로덕션 데이터의 준비 시나리오 (또는 더 큰 데이터 세트를 효과적으로 설정)에 대한 테스트를 통해 결과를 다시 확인할 수 있습니다.
샘플 데이터의 생성 또는 수집과 관련된 질문은 다른 스레드에 대한 것이어야합니다. :) 나는 기회를 얻 자마자이 접근 방식을 시도해보고 내게 어떻게 운임을 주는지 볼 것입니다 - 감사합니다 릭. –
복잡한 (= 읽기 어려운) 쿼리는 #temp 테이블에 대해 실행되는 간단한 (읽기 쉬운) 쿼리 시퀀스로 작성 될 수 있습니다. 개발 과정에서 일련의 간단한 단계를 저장 프로 시저에 넣은 다음 결과를 최종 쿼리와 비교합니다.
간단하게 유지하십시오. 정상적인 개발자의 좌우명! 이것은 내가 취할 접근법과 거의 같게 들립니다. - 때로는 약간의 I/O 또는 CPU, 마음을 기울여야합니다. 이제 성능이 좋은 코드를 작성하고 필요한 경우 나중에 최적화하십시오. –
먼저 모든 하위 쿼리를 개별적으로 시도해보십시오. 한 번에 하나씩 테이블에 가입하십시오. 발생할 수없는 상황에 많은 시간을 소비하지 않도록 데이터베이스의 제약 조건을 확인하십시오 (제약 조건은 친구입니다). 쿼리가 정말 어려워 질 경우 뷰로 생성 할 수있는 부분을 제외하십시오.
생각해보십시오.
대단히 과소 평가되고 있습니다. (관리자에게 거기에 앉아있는 프로그래머가 아무것도하지 않고 앉아있는 프로그래머와 똑같은 것처럼 보였기 때문일 것입니다.)
자세한 내용이 필요합니다. 이것은 매우 광범위한 질문이며 명백하고 모호한 대답을 가질 수 있습니다. 프로그래밍에 대한 믿음이 있어야하며 가능한 한 프로그램을해야하지만 미래에 발생할 모든 사건을 막으려면 향후 속도가 느려질 수 있습니다. –
감사합니다. 케리 - 네 말이 맞아. 내 프로그래밍에 대한 믿음이 있어야 해. (금요일 17시 20 분이 아닌 한!). –