여러 내부 조인을 사용하는 SELECT 문에 문제가 있습니다. 내 코드는 다음과 같습니다:
으아악INNER JOIN을 사용하여 영화 속 배우와 그들이 맡은 역할을 가져오는 것은 작동하는 것 같지만 영화 유형을 가져오는 마지막 두 조인은 작동하지 않으므로 뷰에 작성한 다음 결합할 수 있다고 생각했습니다. 결과를 출력할 때 일어납니다. 그래서 저는 세 가지 견해를 갖게 되었습니다. 하나는 장르, 배우, 역할을 결정하고 다른 하나는 모든 것을 하나로 묶는 것입니다. 문제는 이것이 하나의 큰 SELECT 문과 여러 연결을 사용하는 것보다 낫다는 것입니다.
쿼리를 여러 번 다시 작성해서 여러 가지 방법으로 시도했습니다
뷰가 포함된 쿼리를 실행하면 MySQL/MariaDB의 쿼리 플래너는 테이블에 액세스하는 방법을 결정하기 전에 모든 뷰와 기본 쿼리를 단일 쿼리로 결합합니다. 따라서 뷰, 일반 표현식 및/또는 하위 쿼리를 사용할 때 성능은 본질적으로 동일합니다.
뷰는 일부 쿼리 복잡성을 캡슐화하는 유용한 방법입니다.
또한 신뢰할 수 있는 사용자의 하위 집합에게 기본 테이블에 대한 액세스 권한을 부여하지 않고도 뷰에 대한 액세스 권한을 부여할 수 있습니다.
뷰의 단점은 애플리케이션이 아닌 데이터베이스 관리 시스템에 애플리케이션 로직을 넣는 것과 같습니다. 업데이트가 더 까다롭고 업데이트를 잊어버리기 쉽습니다. (애플리케이션 코드가 업데이트될 때 뷰, 저장 함수 및 저장 프로시저를 업데이트하는 안정적인 애플리케이션 업데이트 워크플로가 있는 경우 이 질문은 관련이 없습니다.)
이러한 유형의 쿼리를 작성하는 좋은 방법은 "최상위" 항목이 포함된 테이블부터 시작하는 것입니다. 당신의 경우에는 영화인 것 같아요. 그런 다음 INNER JOIN을 사용하는 대신 LEFT JOIN을 사용하여 다른 테이블을 조인합니다. 이렇게 하면 일부 하위 개체(배우, 장르 등)가 누락되더라도 결과에서 영화를 볼 수 있습니다.
프로 팁: 가능하다면
whatever01
、whatever02
와 같은 이름을 사용하는 대신 테이블에 포함된 항목(영화, 장르, 배우 등)의 이름을 지정하세요. 쿼리를 살펴보고 쿼리에 대한 이유를 아는 것이 중요하며, 테이블 이름을 사용하면 이 작업이 더 쉬워집니다.