테이블 대신 뷰를 사용하는 경우

실제 테이블에서 실제로 뷰를 사용해야하는 경우는 언제입니까? 이로 인해 어떤 이득을 기대해야합니까?

전반적으로 테이블에 대한 뷰를 사용하면 어떤 이점이 있습니까? 뷰가 처음에 보이는 방식으로 테이블을 디자인해야하지 않습니까?

오, 당신이 고려해야 할 많은 차이점이 있습니다

선택보기 :

1. 뷰는 테이블에 대한 추상화를 제공합니다. 기본 스키마를 수정하지 않고도보기에서 필드를 쉽게 추가 / 제거 할 수 있습니다.
2. 뷰는 복잡한 조인을 쉽게 모델링 할 수 있습니다.
3. 보기는 데이터베이스 관련 항목을 숨길 수 있습니다. 예 : Oracles SYS_CONTEXT 함수 또는 기타 여러 가지를 사용하여 몇 가지 검사를 수행해야하는 경우
4. 실제 테이블이 아닌 뷰에서 직접 GRANTS를 쉽게 관리 할 수 ​​있습니다. 특정 사용자가보기에만 액세스 할 수 있다는 것을 알고 있으면 관리하기가 더 쉽습니다.
5. 뷰는 이전 버전과의 호환성에 도움이 될 수 있습니다. 기본 스키마를 변경할 수 있지만 뷰는 특정 클라이언트에서 이러한 사실을 숨길 수 있습니다.

삽입 / 업데이트보기 :

1. 뷰에서 직접 Oracle의 "WITH CHECK OPTION"절과 같은 기능을 사용하여 뷰의 보안 문제를 처리 할 수 ​​있습니다.

단점

1. 관계에 대한 정보 (기본 키, 외래 키)가 손실됩니다.
2. 뷰가 기본 조인을 숨기므로 뷰를 삽입 / 업데이트 할 수 있는지 여부는 명확하지 않습니다.

보기는 다음을 수행 할 수 있습니다.

• 복잡한 테이블 구조 단순화
• 민감한 데이터를 필터링하고 더 간단한 방식으로 권한을 할당 할 수 있도록하여 보안 모델을 단순화합니다.
• 출력 구조를 변경하지 않고 논리 및 동작을 변경할 수 있습니다 (출력은 동일하게 유지되지만 기본 SELECT는 크게 변경 될 수 있음).
• 성능 향상 (Sql Server Indexed Views)
• 그렇지 않으면 수집하기 어려울 수있는 뷰로 특정 쿼리 최적화를 제공합니다.

그리고 뷰와 일치하도록 테이블을 디자인해서는 안됩니다 . 기본 모델은 데이터의 효율적인 저장 및 검색과 관련이 있어야합니다. 뷰는 부분적으로 복잡성을 추상화 할 수 있도록함으로써 효율적이고 정규화 된 모델에서 발생하는 복잡성을 완화하는 도구입니다.

또한 "테이블에 대한 뷰 사용의 장점은 무엇입니까?"라고 묻는 것은 좋은 비교가 아닙니다. 테이블 없이는 갈 수 없지만 뷰 없이는 할 수 있습니다. 그것들은 각각 매우 다른 이유로 존재합니다. 테이블은 구체적인 모델이고 뷰는 추상화 된 뷰입니다.

매번 복잡한 논리를 따라야하는 경우보기가 허용됩니다. 예를 들어 모든 재무보고에 필요한 원시 데이터를 생성하는보기가 있습니다. 모든 보고서에서이보기를 사용하면 모든 보고서가 하나의 조인 집합을 사용하고 다른 보고서가 다른 결과를 제공하는 하나를 사용하는 것을 잊어 버리는 대신 동일한 데이터 집합에서 작업하게됩니다.

사용자를 특정 데이터 하위 집합으로 제한하려는 경우보기가 허용됩니다. 예를 들어, 레코드를 삭제하지 않고 현재 레코드 만 활성으로 표시하고 이전 버전을 비활성으로 표시하는 경우보기를 사용하여 활성 레코드 만 선택하도록 할 수 있습니다. 이것은 사람들이 쿼리에 where 절을 넣는 것을 잊고 나쁜 결과를 얻는 것을 방지합니다.

보기를 사용하여 사용자가 레코드 집합에만 액세스 할 수 있도록 할 수 있습니다. 예를 들어 특정 클라이언트에 대한 테이블보기와 테이블에 대한 보안 권한이 없으면 해당 클라이언트의 사용자가 데이터를 볼 수만 있음을 의미 할 수 있습니다. 그 클라이언트를 위해.

뷰는 데이터베이스를 리팩토링 할 때 매우 유용합니다.

보기를 사용하여보기를 호출 할 때보기는 허용되지 않습니다. 이는 최소한 SQL Server에서 끔찍한 성능을 초래할 수 있습니다. 누군가가 그런 방식으로 데이터베이스를 추상화하고 성능이 끔찍하고 시간 초과가 빈번했기 때문에 우리는 거의 수백만 달러의 클라이언트를 잃었습니다. 성능 문제가 전적으로 우리 잘못 이었기 때문에 우리는 클라이언트가 아닌 수정 비용을 지불해야했습니다. 뷰가 뷰를 호출 할 때 기본 뷰를 완전히 생성해야합니다. 저는 뷰를 뷰라고 부르는 뷰를 보았습니다. 그리고 사용자가 궁극적으로 필요로하는 세 가지를보기 위해 수백만 개의 레코드가 생성되었습니다. 이 뷰 중 하나가 레코드의 간단한 개수 (*)를 수행하는 데 8 분이 걸렸던 것을 기억합니다. 뷰를 호출하는 뷰는 매우 좋지 않은 아이디어입니다.

일반적으로 동일한 테이블의 필드 만 업데이트 할 수 있으므로 뷰는 종종 레코드를 업데이트하는 데 사용하는 것이 좋지 않습니다 (다시 말하지만 이것은 SQL Server이며 다른 데이터베이스는 다를 수 있음). 이 경우 사용 가능한 필드를 알 수 있도록 테이블을 직접 업데이트하는 것이 더 합리적입니다.

뷰는 여러 테이블에서 선택하거나 테이블의 하위 집합을 가져와야 할 때 편리합니다.

데이터베이스가 잘 정규화 되도록 테이블을 디자인해야합니다 (최소 중복). 이로 인해 쿼리가 다소 어려울 수 있습니다.

뷰는 약간 분리되어있어 저장된 것과는 다르게 테이블의 데이터 를 볼 수 있습니다 .

일반적인 방법은 사용자에게보다 비정규 화 된 데이터 모델을 제공하기 위해 뷰에서 조인을 숨기는 것입니다. 다른 용도에는 보안 (예 : 특정 열 및 / 또는 행 숨기기) 또는 성능 (구체화 된 뷰의 경우)이 포함됩니다.

뷰를 고려하지 않고 테이블을 디자인해야합니다.
조인 및 조건을 저장하는 것 외에도 뷰에는 성능상의 이점이 있습니다. SQL Server는 뷰에서 실행 계획을 계산하고 저장할 수 있으므로 "즉석"SQL 문보다 빠르게 만들 수 있습니다.
보기는 또한 필드 수준에서 사용자 액세스와 관련된 작업을 쉽게 할 수 있습니다.

우선 이름에서 알 수 있듯이 뷰는 변경할 수 없습니다. 뷰는 DB에 저장된 쿼리에서 생성 된 가상 테이블에 불과하기 때문입니다. 이 때문에보기의 몇 가지 특성이 있습니다.

• 데이터의 하위 집합 만 표시 할 수 있습니다.
• 여러 테이블을 단일 뷰로 결합 할 수 있습니다.
• 보기에서 데이터를 집계 할 수 있습니다 (개수 선택).
• 보기는 실제로 데이터를 보유하지 않으며 기본 테이블의 가상 집계이기 때문에 테이블 스페이스가 필요하지 않습니다.

따라서 뷰가 테이블보다 더 잘 맞는 수 많은 사용 사례가 있습니다. 웹 사이트에서 활성 사용자 만 표시하는 것에 대해 생각해보십시오. 실제로 DB에있는 데이터의 하위 집합 (활성 및 비활성 사용자)에서만 작동하므로보기가 더 좋습니다.

이 기사를 확인 하십시오

도움이 되었기를 바랍니다 ..

에 따르면 위키 백과 ,

뷰는 테이블에 비해 많은 이점을 제공 할 수 있습니다.

• 뷰는 테이블에 포함 된 데이터의 하위 집합을 나타낼 수 있습니다 .

• 뷰는 기본 테이블이 외부 세계 에 노출되는 정도를 제한 할 수 있습니다. 지정된 사용자는 뷰를 쿼리 할 수있는 권한이있는 반면 나머지 기본 테이블에 대한 액세스는 거부 될 수 있습니다.

• 뷰는 여러 테이블 을 단일 가상 테이블 로 결합하고 단순화 할 수 있습니다 .

• 뷰는 데이터베이스 엔진이 데이터 (합계, 평균 등)를 집계하고 계산 된 결과를 데이터의 일부로 표시하는 집계 테이블 역할을 할 수 있습니다 .

• 보기는 데이터 의 복잡성 을 숨길 수 있습니다 . 예를 들어보기가 Sales2000 또는 Sales2001로 표시되어 실제 기본 테이블을 투명하게 분할 할 수 있습니다.

• 뷰는 저장하는 데 매우 적은 공간을 차지합니다 . 데이터베이스에는보기에 대한 정의 만 포함되며 제공하는 모든 데이터의 복사본은 포함되지 않습니다.

• 보기는 사용 된 SQL 엔진에 따라 추가 보안을 제공 할 수 있습니다 .