데이터베이스 뷰가 많아도 괜찮나요?

Question

저는 Microsoft SQL Server 2005 데이터베이스 뷰를 사용하여 수백 개의 Crystal Reports 보고서를 생성하는 경우가 드물게(월별/분기별) 있습니다.해당 뷰는 내가 읽지 않는 동안 CPU 주기와 RAM을 낭비하고 있습니까?뷰에서 거의 읽지 않으므로 대신 저장 프로시저, 임시 테이블 또는 단기 일반 테이블을 사용해야 합니까?

저는 DBA가 아니기 때문에 데이터베이스 서버 내부에서 무슨 일이 일어나고 있는지 모릅니다.

데이터베이스 뷰가 너무 많을 수 있나요?모범 사례로 간주되는 것은 무엇입니까?

Answer 1

대부분의 경우 그것은 중요하지 않습니다.예, SQL Server는 SELECT * FROM 테이블을 구문 분석할 때 더 많은 선택권을 가지게 되지만(시스템 카탈로그에서 '테이블'을 찾아야 함) 이를 위해 고도로 최적화되어 있으며 충분한 RAM이 있는 경우(요즘 대부분의 서버는 그렇습니다) , 조회수가 0회와 1,000회 사이에는 차이가 없습니다.

그러나 사람의 관점에서 볼 때 "수백" 개의 뷰가 수행하는 작업을 관리하고 파악하는 것은 아마도 불가능할 수 있으므로 거기에 중복된 코드가 많이 있을 가능성이 높습니다.이러한 중복된 보기에 포함된 일부 비즈니스 규칙이 변경되면 어떻게 됩니까?

뷰의 주요 요점은 비즈니스 로직을 의사 테이블로 캡슐화하는 것입니다(따라서 개인 테이블이 있을 수 있지만 마법을 수행하는 "active_persons"라는 뷰가 있을 수 있습니다).각 보고서가 너무 분리되고 고유하여 재사용할 수 없는 경우를 제외하고 각 보고서에 대한 보기를 만드는 것은 어리석은 일입니다.

Answer 2

뷰는 미리 설정된 매개변수를 사용하여 자주 실행하는 쿼리입니다.항상 동일한 데이터를 보게 될 것이라는 점을 알고 있다면 사용하기 쉽고 데이터 바인딩을 위해 뷰를 만들 수 있습니다.

즉, 보기에서 선택하면 보기 정의 쿼리가 실행 중인 쿼리와 함께 실행됩니다.

예를 들어, vwCustomersWhoHavePaid가 다음과 같은 경우:

Select * from customers where paid = 1

실행 중인 쿼리는 8월 1일 이후에 지불한 고객을 다음과 같은 형식으로 반환합니다.

Select * from vwCustomersWhoHavePaid where datepaid > '08/01/08'

실제로 실행 중인 쿼리는 다음과 같습니다.

Select * from (Select * from customers where paid = 1) where datepaid > '08/01/08'

이는 뷰를 생성할 때 명심해야 할 사항으로, 자주 보는 데이터를 저장하는 방법입니다.이는 데이터를 정리하여 액세스하기 쉽게 만드는 방법일 뿐입니다.

Answer 3

뷰는 호출될 때만 CPU/메모리 리소스를 차지합니다.

어쨌든 가장 좋은 방법은 통합할 수 있는 것을 통합하고 제거할 수 있는 것을 제거하는 것입니다. 그리고 문자 그대로 보고서에서만 사용되는 경우 특정 보기를 찾을 때 쉽게 그룹화할 수 있도록 보기에 대한 일관된 명명 표준을 선택합니다. .

또한 트랜잭션 격리가 꼭 필요한 경우가 아니라면 쿼리에 NOLOCK 테이블 힌트를 사용하는 것이 좋습니다.

-- 케빈 페어차일드

Answer 4

물어:뒤에서 무슨 일이 벌어지고 있는 걸까요?

뷰는 SQL 텍스트 묶음입니다.쿼리가 뷰를 사용하면 SQL Server는 해당 SQL 텍스트를 쿼리에 배치합니다.이는 최적화 전에 발생합니다.결과적으로 최적화 프로그램은 최상의 실행 계획을 위해 두 개의 별도 코드 조각 대신 결합된 코드를 고려할 수 있습니다.

쿼리 실행 계획을 살펴봐야 합니다!거기에는 배울 것이 너무 많습니다.

SQL Server에도 클러스터링된 뷰.ㅏ 클러스터링된 뷰 시스템에서 유지 관리되는 결과 집합입니다(기본 테이블의 각 삽입/업데이트/삭제는 테이블에서 삽입/업데이트/삭제를 유발할 수 있음). 클러스터링된 뷰의 데이터).뷰가 다음과 같은 방식으로 작동한다고 생각하는 것은 일반적인 실수입니다. 클러스터된 뷰 작동하다.