답변:
보기에는 몇 가지 이점이 있습니다.
1.보기는 복잡성을 숨길 수 있습니다
여러 테이블을 조인해야하거나 복잡한 논리 또는 계산이 필요한 쿼리가있는 경우 해당 논리를 모두 뷰로 코딩 한 다음 테이블처럼 뷰에서 선택할 수 있습니다.
2. 뷰는 보안 메커니즘으로 사용될 수 있습니다
뷰는 테이블에서 특정 열 및 / 또는 행과 기본 테이블 대신 뷰에 설정된 권한을 선택할 수 있습니다. 이를 통해 사용자가 볼 필요가있는 데이터 만 표면 처리 할 수 있습니다.
3. 뷰는 레거시 코드 지원을 단순화 할 수 있습니다
많은 코드를 손상시킬 수있는 테이블을 리팩토링해야하는 경우 테이블을 동일한 이름의보기로 바꿀 수 있습니다. 뷰는 원래 테이블과 정확히 동일한 스키마를 제공하지만 실제 스키마는 변경되었습니다. 이렇게하면 테이블을 참조하는 레거시 코드가 손상되지 않도록하여 여가 시간에 레거시 코드를 변경할 수 있습니다.
이들은 뷰가 어떻게 유용 할 수 있는지에 대한 많은 예 중 일부입니다.
무엇보다도 보안에 사용될 수 있습니다. "고객"테이블이있는 경우 모든 영업 사원에게 이름, 주소, 우편 번호 등 필드에 액세스 할 수 있지만 credit_card_number는 액세스하지 못하게 할 수 있습니다. 액세스해야하는 열만 포함하는보기를 작성한 다음보기에 대한 액세스 권한을 부여 할 수 있습니다.
Select name, address, zipcode from customer대신 목적을 제공하지 creating a view않습니까?
select * from customer하여 모든 것에 액세스 할 수 있습니다. 테이블이 아닌 뷰에 대한 액세스 권한을 부여하면 뷰에없는 필드에 액세스 할 수 없습니다 .
뷰는 쿼리를 캡슐화 한 것입니다. 조회로 전환 된 쿼리는 복잡 해지는 경향이 있으며 재사용을위한 조회로 저장하는 것이 유리할 수 있습니다.
일반적으로보고 목적으로 자주 사용되는 데이터를 비정규 화 및 / 또는 집계하기위한보기를 만듭니다.
편집하다
정교하게 말하면, 개인, 회사, 역할, 소유자 유형, 주문, 주문 세부 정보, 주소 및 전화 번호가있는 데이터베이스가 있어야합니다. 개인 테이블에는 직원과 연락처 및 주소가 모두 저장되어 있습니다. 전화 테이블에는 개인과 회사 모두의 전화 번호가 저장되어 있으며 개발 팀은 직원 별 판매, 고객 별 판매, 지역별 판매, 월별 판매와 같은 보고서를 생성하거나 개발자가 아닌 사람이보고 데이터에 액세스 할 수 있도록하는 업무를 맡았습니다. , 상태 별 고객 등 나는 실제 엔티티의보다 통합 된보기 (말장난 의도가 없음)를 사용할 수 있도록 데이터베이스 엔티티 간의 관계를 비정규 화하는보기 세트를 작성합니다. 다음과 같은 장점이 있습니다.
몇 가지 이유 : 복잡한 조인이있는 경우 액세스 할 때마다 항상 조인이 올 바르고 개발자가 필요로하는 모든 테이블을 기억할 필요가 없도록보기를 갖는 것이 가장 좋습니다. 일반적으로 이는 모든 재무 보고서가 동일한 데이터 세트를 기반으로하는 것이 매우 중요한 재무 애플리케이션에 대한 것일 수 있습니다.
사용자가 볼 수있는 레코드를 제한하려는 경우 뷰를 사용하고 기본 테이블이 아닌 뷰에만 액세스 권한을 부여한 후 뷰를 조회 할 수 있습니다.
Crystal 보고서는 저장된 procs에 뷰를 사용하는 것을 선호하므로 많은 보고서 작성을하는 사람들은 많은 뷰를 사용하는 경향이 있습니다.
뷰는 데이터베이스를 리팩토링 할 때 매우 유용합니다. 변경 사항을 숨겨서 이전 코드가보기를 작성하여 변경 사항을 볼 수 없도록 할 수 있습니다. 리팩토링 데이터베이스를 읽으면 리팩토링하는 매우 강력한 방법이므로 이것이 어떻게 작동하는지 확인하십시오.
저장 프로 시저에 비해 뷰의 주요 이점 중 하나는 테이블을 사용하는 것처럼 뷰를 사용할 수 있다는 것입니다. 즉, FROM조회 절 에서 뷰를 직접 참조 할 수 있습니다 . 예, SELECT * FROM dbo.name_of_view.
다른 모든 방법으로 저장 프로 시저가 더 강력합니다. 당신은 다음과 같은 매개 변수를 전달할 수 있습니다 out당신이 할 수있는, 효과적으로 한 번에 여러 값을 반환 할 수 있도록 매개 변수 SELECT, INSERT, UPDATE, 및 DELETE운영, 등 등
FROM절 내에서 View의 쿼리 기능을 원하지만 매개 변수를 전달하려는 경우에도 그렇게하는 방법이 있습니다. 이를 테이블 반환 함수라고합니다.
다음은이 주제에 대한 매우 유용한 기사입니다.
편집 : 그건 그렇고, 이런 종류의 질문은 테이블 뷰 함수에 비해 뷰가 어떤 이점을 가지고 있습니까? 나는 그것에 대한 좋은 대답이 없지만 뷰를 만드는 T-SQL 구문은 테이블 반환 함수보다 간단하며 데이터베이스 사용자는 뷰에 더 익숙 할 수 있습니다.
ORM과 테이블 사이에 좋은 "중간자"역할을 할 수 있습니다.
예:
SomeColumn 열이 다른 테이블로 이동하고 일대 다 관계를 갖도록 구조를 변경해야하는 Person 테이블이있었습니다.
그러나 개인과 관련하여 대부분의 시스템은 SomeColumn을 단일 항목으로 사용했습니다. 우리는 뷰를 사용하여 SomeColumns를 모두 모아서 뷰에 넣었습니다.
이는 데이터 계층이 변경되었지만 비즈니스 요구 사항이 근본적으로 변경되지 않았기 때문에 작동했기 때문에 비즈니스 개체를 변경할 필요가 없었습니다. 비즈니스 객체가 변경되어야한다면 이것이 가능한 해결책이라고 생각하지는 않지만 뷰는 확실히 좋은 중간 지점으로 작동합니다.
특정 데이터 보기에 집중하기 사용자는 관심있는 특정 데이터 및 담당하는 특정 작업에 집중할 수 있습니다. 불필요한 데이터는보기에서 제외 될 수 있습니다. 또한 사용자는 기본 테이블의 데이터가 아닌 뷰에 정의 된 데이터 만 볼 수 있기 때문에 데이터 보안이 향상됩니다. 보안 목적으로보기를 사용하는 방법에 대한 자세한 내용은보기를 보안 메커니즘으로 사용을 참조하십시오.
데이터 조작 단순화 뷰는 사용자가 데이터를 조작하는 방법을 단순화 할 수 있습니다. 자주 사용하는 조인, 프로젝션, UNION 쿼리 및 SELECT 쿼리를 뷰로 정의하여 사용자가 해당 데이터에 대해 추가 작업을 수행 할 때마다 모든 조건과 자격을 지정할 필요가 없도록 할 수 있습니다. 예를 들어,보고 목적으로 사용되고 하위 쿼리, 외부 조인 및 집계를 수행하여 테이블 그룹에서 데이터를 검색하는 복잡한 쿼리를보기로 만들 수 있습니다. 보고서를 생성 할 때마다 기본 쿼리를 작성하거나 제출할 필요가 없으므로 뷰는 데이터에 대한 액세스를 단순화합니다. 대신 조회가 조회됩니다. 데이터 조작에 대한 자세한 정보.
논리적으로 매개 변수화 된보기로 작동하는 인라인 사용자 정의 함수 또는 WHERE 절 검색 조건에 매개 변수가있는보기를 작성할 수도 있습니다. 자세한 내용은 인라인 사용자 정의 함수를 참조하십시오.
데이터 보기 를 사용자 지정 하면 서로 다른 사용자가 동일한 데이터를 동시에 사용하는 경우에도 다른 방식으로 데이터를 볼 수 있습니다. 이것은 많은 다른 관심과 기술 수준을 가진 사용자가 동일한 데이터베이스를 공유 할 때 특히 유리합니다. 예를 들어, 계정 관리자와 거래하는 고객에 대한 데이터 만 검색하는보기를 작성할 수 있습니다. 보기는보기를 사용하는 계정 관리자의 로그인 ID를 기반으로 검색 할 데이터를 판별 할 수 있습니다.
데이터 를 내보내고 가져 오는 방법 보기를 사용하여 다른 응용 프로그램으로 데이터를 내보낼 수 있습니다. 예를 들어 펍 데이터베이스의 상점 및 판매 테이블을 사용하여 Microsoft® Excel을 사용하여 판매 데이터를 분석 할 수 있습니다. 이를 위해 상점 및 판매 테이블을 기반으로보기를 작성할 수 있습니다. 그런 다음 bcp 유틸리티를 사용하여보기에서 정의한 데이터를 내보낼 수 있습니다. INSERT 문을 사용하여 행을보기에 삽입 할 수 있도록 bcp 유틸리티 또는 BULK INSERT 문을 사용하여 데이터 파일에서 특정보기로 데이터를 가져올 수도 있습니다. 데이터를 뷰에 복사하기위한 제한 사항에 대한 자세한 정보는 INSERT를 참조하십시오. bcp 유틸리티 및 BULK INSERT 문을 사용하여보기와 데이터를 복사하는 방법에 대한 자세한 정보는보기에서 복사 또는보기에서 복사를 참조하십시오.
분할 된 데이터를 결합하려면 뷰 내에서 Transact-SQL UNION 집합 연산자를 사용하면 별도의 테이블에서 두 개 이상의 쿼리 결과를 단일 결과 집합으로 결합 할 수 있습니다. 이는 분할 된 뷰라는 단일 테이블로 사용자에게 나타납니다. 예를 들어 한 테이블에 Washington의 판매 데이터가 있고 다른 테이블에 California의 판매 데이터가있는 경우 해당 테이블의 UNION에서 뷰를 만들 수 있습니다. 보기는 두 지역의 판매 데이터를 나타냅니다. 분할 된 뷰를 사용하려면 각 테이블에 추가 할 수있는 데이터 범위를 결정하는 제약 조건을 지정하여 동일한 여러 테이블을 만듭니다. 그런 다음이 기본 테이블을 사용하여보기가 작성됩니다. 뷰를 쿼리 할 때 SQL Server는 쿼리의 영향을받는 테이블을 자동으로 확인하고 해당 테이블 만 참조합니다. 예를 들어 쿼리에서 Washington 주에 대한 판매 데이터 만 필요하다고 지정하면 SQL Server는 Washington 판매 데이터가 포함 된 테이블 만 읽습니다. 다른 테이블에는 액세스하지 않습니다.
분할 된 뷰는 동일한 데이터베이스의 테이블뿐만 아니라 원격 서버와 같은 여러 이기종 소스의 데이터를 기반으로 할 수 있습니다. 예를 들어 조직의 다른 지역에 대한 데이터를 저장하는 각기 다른 원격 서버의 데이터를 결합하기 위해 각 데이터 소스에서 데이터를 검색하는 분산 쿼리를 만든 다음 해당 분산 쿼리를 기반으로보기를 만들 수 있습니다. 모든 쿼리는 쿼리에서 요청한 데이터가 포함 된 원격 서버의 테이블에서 데이터 만 읽습니다. 뷰에서 분산 쿼리가 참조하는 다른 서버에는 액세스 할 수 없습니다.
여러 테이블 또는 여러 서버에서 데이터를 분할하면 스캔 할 데이터가 적기 때문에 일부 데이터에만 액세스하는 쿼리가 더 빠르게 실행될 수 있습니다. 테이블이 다른 서버 나 여러 프로세서가있는 컴퓨터에있는 경우 쿼리와 관련된 각 테이블을 병렬로 스캔하여 쿼리 성능을 향상시킬 수 있습니다. 또한 인덱스 다시 작성 또는 테이블 백업과 같은 유지 관리 작업이보다 빠르게 실행될 수 있습니다. 분할 된 뷰를 사용하면 데이터가 여전히 단일 테이블로 표시되며 올바른 기본 테이블을 수동으로 참조하지 않고도 쿼리를 쿼리 할 수 있습니다.
이러한 조건 중 하나가 충족되면 분할 된 뷰를 업데이트 할 수 있습니다. INSTEAD OF 트리거는 INSERT, UPDATE 및 DELETE 문을 지원하는 논리를 사용하여 뷰에서 정의됩니다.
뷰와 INSERT, UPDATE 및 DELETE 문은 모두 업데이트 가능한 분할 뷰에 대해 정의 된 규칙을 따릅니다. 자세한 내용은 분할 된 뷰 만들기를 참조하십시오.
https://technet.microsoft.com/en-us/library/aa214282(v=sql.80).aspx#sql:join
이를 수행하는 데는 여러 가지 이유가 있습니다. 때로는 모든 조인을 수행하는 대신 테이블 이름을 쿼리 할 수 있으므로 일반적인 조인 쿼리를 쉽게 수행 할 수 있습니다.
또 다른 이유는 데이터를 다른 사용자로 제한하는 것입니다. 예를 들어 :
표 1 : 열-USER_ID; USERNAME; SSN
관리자는 실제 테이블에 대한 권한을 가질 수 있지만 SSN에 액세스하기를 원하지 않는 사용자는 다음과 같이보기를 작성합니다.
뷰 사용자 이름을 SELECT user_id, username FROM Table1;
그런 다음 테이블이 아닌 뷰에 액세스 할 수있는 권한을 부여하십시오.
다음은 권한과 함께보기를 사용하여 사용자가 테이블에서 업데이트 할 수있는 열을 제한하는 방법입니다.
/* This creates the view, limiting user to only 2 columns from MyTestTable */
CREATE VIEW dbo.myTESTview
WITH SCHEMABINDING AS
SELECT ID, Quantity FROM dbo.MyTestTable;
/* This uses the view to execute an update on the table MyTestTable */
UPDATE dbo.myTESTview
SET Quantity = 7
WHERE ID = 1테이블의 스냅 샷 및 / 또는 보기 (읽기 전용 방식) 를보고자 할 때
쿼리를 실행할 때만 저장 프로 시저에 대한 뷰를 사용하고 싶습니다. 또한 뷰는 보안을 단순화하고 여러 테이블에 대한 삽입 / 업데이트를 쉽게하는 데 사용될 수 있으며 데이터 스냅 샷 / 구체화 (오래 실행되는 쿼리 실행 및 결과 캐시)에 사용할 수 있습니다.
실시간으로 정확하게 유지할 필요가없는 그리운 쿼리를 실행하기 위해 구체화 된 뷰를 사용했습니다.
이것은 귀하의 질문에 정확하게 대답하지는 않지만 Materialized Views를 언급 할 가치가 있다고 생각했습니다 . 내 경험은 대부분 Oracle과 관련이 있지만 SQL-Server는 상당히 유사합니다.
XML 성능 문제를 해결하기 위해 아키텍처에서 비슷한 것을 사용했습니다. Google 시스템은 XML로 저장된 많은 데이터를 사용하여 설계되었으며 애플리케이션은 특정 값을 쿼리해야 할 수 있습니다. 많은 XMLType을 처리하고 많은 행에서 XPath를 실행하면 성능에 큰 영향을 미치므로 구체화 된 뷰 형식을 사용하여 기본 테이블이 변경 될 때마다 원하는 XML 노드를 관계형 테이블로 추출합니다. 이는 요청시 쿼리를 실행하는 표준보기와 달리 특정 시점에서 쿼리의 실제 스냅 샷을 효과적으로 제공합니다.
내 데이터에 대해 호출 할 수있는 방법으로 저장 프로 시저를 더 많이 볼 수 있지만 뷰는 쿼리 또는 저장 프로 시저를 만들 수있는 기본 데이터의 합성 버전을 만드는 메커니즘을 제공합니다. 단순화 또는 집계가 의미가있을 때 뷰를 작성하겠습니다. 매우 구체적인 서비스를 제공하고자 할 때 저장 프로 시저를 작성하겠습니다.
뷰에 대한 흥미로운 점 중 하나는 Microsoft Access에서 테이블로 볼 수 있다는 것입니다. ODBC를 사용하여 Microsoft Access 프런트 엔드를 SQL 데이터베이스에 연결하면 사용 가능한 테이블 목록에 테이블과 뷰가 표시됩니다. 따라서 MS Access에서 복잡한 보고서를 준비하는 경우 SQL Server에서 조인 및 쿼리를 수행하고 수명을 크게 단축 할 수 있습니다. MS Excel에서 쿼리를 준비하기위한 Ditto
프로덕션 데이터베이스에는 10 개 정도의 뷰만 있습니다. 나는 항상 사용하는 열에 여러 개를 사용합니다. 내가 사용하는 한 세트는 7 개의 테이블에서 왔으며 일부는 외부 조인이 있으며 일부는 선택적으로 해당 뷰를 호출하고 하나 또는 두 개의 조인 만하면된다는 것을 다시 쓰지 않고 다시 작성합니다. 나에게 그것은 단지 시간 절약입니다.
보안을 위해 : 각 사용자에게 사용자 또는 사용자 그룹이 볼 수있는 특정 데이터를 포함하는 작은보기 세트를 통해서만 데이터베이스에 액세스 할 수있는 권한을 부여하여 다른 데이터에 대한 사용자 액세스를 제한합니다.
쿼리 및 구조의 단순성 : 뷰는 여러 테이블에서 데이터를 가져와 단일 테이블을 표시하여 정보를 단순화하고 다중 테이블 쿼리를 뷰에 대한 단일 테이블 쿼리로 전환하고 사용자에게 데이터베이스 구조의 특정 뷰를 제공합니다. 특정 사용자 또는 사용자 그룹에 특정한 가상 테이블 세트로서의 데이터베이스.
일관된 데이터베이스 구조 작성 : 기본 소스 테이블이 변경 되더라도 뷰는 일관되고 변경되지 않은 데이터베이스 구조 이미지를 제공합니다.