내가 table1, table2 ... table5라는 5 개의 테이블을 가지고 있다고 가정 해 보겠습니다. 나는 이미 table1, 2 및 3을 결합하여 query1이라는 뷰/쿼리를 만들었습니다.쿼리를 쿼리하고 있습니까?
이제 다섯 개의 테이블을 모두 조인해야하는 뷰를 만들고 싶습니다. 내 질문은 query1을 사용하여 table4와 table5를 조인하는 것이 좋습니까? 아니면 하나씩 5 개의 테이블을 조인하는 것이 더 좋습니까?
두 개의 뷰 또는 뷰와 테이블을 결합하면 같은 뷰를 수정하면 해당 뷰에 종속적이기 때문에 전체 쿼리를 재구성해야합니다.
쿼리를 뷰에 종속시키지 않으려면 먼저 뷰를 만드는 이유가 무엇인지 스스로 물어야합니다.
당신의 5 테이블 쿼리 단지 같은 테이블이 query1보기에서하지만 실제 사실에 합류하는 방법을 동일하게을 발생하는 방식으로 table1, table2 및 table3에 가입하는 경우가 완전히 다른 의미하고, 제 생각에는, 그것은 완벽하게 괜찮을 것입니다 query1 두 번째보기/쿼리에서 사용할 수 없습니다.
두 번째보기/쿼리가 이미 query1에 구현 된 동일한 비즈니스 규칙을 재현하려면 코드를 복제 할 필요가 없습니다. 이는 부분적으로 뷰의 핵심입니다. 코드를 작성하면 여러 번 사용해야하는 경우 동일한 코드를 반복하지 않아도됩니다. query1을 변경할 때 다른 종속 쿼리 및/또는 뷰가 그에 따라 출력을 변경하는 것이 좋습니다.
물론보기에서 변경 사항을 적용하려면 다른 쿼리 및/또는보기를 변경해야합니다. 그것이 현재 가장 염려되는 부분이라면, 오랜 시간 동안 데이터베이스를 사용 한 후에 이러한 변경의 가능성을 줄이기 위해 뷰를 올바르게 계획하는 데 시간을 투자하는 것이 좋습니다.
그래서 기본적으로 선택하면 각 뷰에서 논리를 복제하여 서로 종속되지 않도록하거나 필요한 경우 활발하게 뷰를 사용하지만 에의 체인을 만드는 상황에서 위험이 발생합니다. 하나의 특정보기 은이 필요하기 때문에 변경됩니다. 그러나 이전에 말했듯이, 다시보기를 올바르게 설계하면 위험을 최소화 할 수 있습니다. .
원하는대로 수행하십시오.
쿼리 최적화 프로그램은 코드를 분석하고 동일한 실행 계획을 작성합니다.
미리 계획에 대한 아이디어가 가장 인상적입니다. 그게 내가 생각하기에 이전에 숨겨진 문제라고 생각합니다. – Arman
두 번째 질문이 뷰일 경우 코드를 다시 작성해야합니다. ciews를 호출하는 뷰는 잘못 수행하는 데이터베이스의 원인 중 하나입니다. 그것들은 또한 관리하기가 극히 어려우며,이 뷰어는 어떤 뷰를 변경해야 하는지를 결정하기 위해 체인을 거치지 않고 맨 위에 다른 뷰를 추가하는 것이 중요하다는 것을 알게됩니다. 결국 같은 테이블에 15 번 합류하여 수백만 개의 레코드를 생성하여 결과 셋을 얻을 수 있습니다.이 좋은 생각 이었지만 응용 프로그램 개발에 어려움을 겪는 곳에서이 사실을 알 수 있습니다. 뷰를 호출하기 위해 뷰를 사용하지 마십시오. – HLGEM
@HLGEM : 뷰를 호출하는 모든 뷰가 성능 측면에서 문제가되는 것은 아닙니다.예, 여러 번 자체 조인되는 테이블을 생성하는 경우 성능 문제가 발생할 수 있지만 좋은 계획 (또는 적어도 기존 코드베이스의 적절한 분석)이 실행되어야하는 부분이라고 생각합니다. 그 (즉, 다중 자체 조인)가 아닌 경우 중첩 뷰는 성능 측면에서 완벽합니다. (중첩 자체에서 발생하는 문제는 내 답변에있는 내용을 다뤘다 고 생각합니다.) –