RDBMS에서 어떤 뷰가 사용되는지에 대한 일반적인 아이디어를 얻으려고합니다. 즉, 뷰가 무엇인지, 어떻게 만드는지 압니다. 나는 또한 내가 과거에 무엇을 사용했는지 알고 있습니다.
하지만 뷰가 어떤 용도로 유용하고 어떤 용도로 유용하지 않아야하는지 철저히 이해하고 싶습니다. 더 구체적으로:
(기록을 위해 이러한 질문 중 일부는 의도적으로 순진한 것입니다. 이것은 부분적으로 개념 확인입니다.)
답변:
1) 뷰가 유용한 이유는 무엇입니까?
IOPO In One Place Only
• 데이터 자체를 고려하든 조인 된 테이블을 참조하는 쿼리를 고려하든 뷰를 활용하면 불필요한 중복을 피할 수 있습니다.
•보기는 또한 테이블에 대한 직접 액세스를 방지하는 추상화 계층을 제공합니다 (그리고 결과적으로 물리적 종속성을 참조하는 handcuffing). 사실, 나는 생각 좋은 연습 1 과 같은 뷰를 포함, (뷰 및 테이블 반환 함수 사용)하여 기본 데이터 만 추상화 된 액세스를 제공하는 1 내가 말한대로 나는 hafta가 할 일 "의 좋은 거래 거기 인정을,하지 I로 그 조언에 "할";)CREATE VIEW AS
SELECT * FROM tblData
2) 뷰를 사용하지 말아야 할 때 뷰를 사용하고 싶은 상황이 있습니까?
뷰 조인의 성능이 문제였습니다 (예 : SQL 2000). 나는 전문가는 아니지만 한동안 그것에 대해 걱정하지 않았습니다. (또는 현재 뷰 조인을 사용하고있는 곳을 생각할 수 없습니다.)
뷰가 과도 할 수있는 또 다른 상황은 뷰가 하나의 호출 위치에서만 참조되고 파생 테이블이 대신 사용될 수있는 경우입니다. 익명 유형이 한 번만 사용 / 참조되는 경우 .NET의 클래스보다 익명 유형이 선호되는 것처럼.
• http://msdn.microsoft.com/en-us/library/ms177634.aspx에서 파생 된 테이블 설명을 참조하십시오.
3) 테이블 반환 함수 대신 뷰를 사용하거나 그 반대의 경우 왜 사용합니까?
(성능 이유 제외) 테이블 반환 함수는 매개 변수가있는 뷰와 기능적으로 동일합니다. 실제로 일반적인 단순 테이블 반환 함수 사용 사례는 단일 개체의 기존 뷰에 WHERE 절 필터를 추가하는 것입니다.
4) 한눈에 알 수없는 뷰가 유용 할 수있는 상황이 있습니까?
나는 내 머리 꼭대기의 명백하지 않은 사용을 생각할 수 없습니다. (내가 할 수 있다면 분명하게 만들 것이라고 생각합니다.)
어떤 의미에서 뷰는 비정규 화됩니다. 더 의미있는 방식으로 데이터를 제공하려면 비정규 화가 필요한 경우가 있습니다. 이것은 많은 응용 프로그램이 객체에서 도메인 모델링을 통해 어쨌든 수행하는 작업입니다. 비즈니스 관점에 더 가깝게 일치하는 방식으로 데이터를 제공하는 데 도움이됩니다.
다른 사람들이 언급 한 것 외에도 뷰는 응용 프로그램에서 더 복잡한 SQL 쿼리를 제거하는 데 유용 할 수 있습니다.
예를 들어, 응용 프로그램에서 다음을 수행하는 대신 :
sql = "select a, b from table1 union select a, b from table2";
뷰에 추상화 할 수 있습니다.
같은 뷰 작성 union_table1_table2_v
선택하십시오을, 표 1의 B의
조합은
표 2에서, A, B를 선택
앱 코드에는 다음이 있습니다.
sql = "union_table1_table2_v에서 a, b 선택";
또한 데이터 구조가 변경되는 경우 앱 코드를 변경하고 다시 컴파일하고 다시 배포 할 필요가 없습니다. db에서 뷰를 변경하면됩니다.
OP는 뷰를 사용하려는 유혹이있는 상황이 있는지 물었지만 적절하지 않습니다.
보기를 사용하지 않으려는 것은 복잡한 조인을 대체하는 것입니다. 즉, 문제를 작은 조각으로 나누는 절차 적 프로그래밍 습관이 하나의 큰 조인 대신 함께 결합 된 여러 뷰를 사용하도록 유도하지 마십시오. 이렇게하면 기본적으로 하나의 큰 쿼리가 아닌 여러 개의 개별 쿼리를 수행하므로 데이터베이스 엔진의 효율성이 떨어집니다.
예를 들어 테이블 A, B, C 및 D를 함께 조인해야한다고 가정 해 보겠습니다. 테이블 A와 B에서 뷰를 만들고 C와 D에서 뷰를 만든 다음 두 뷰를 결합하고 싶을 수 있습니다. A, B, C, D를 하나의 쿼리로 조인하는 것이 훨씬 좋습니다.
지금까지의 응답은 정확합니다. 뷰는 보안, 비정규 화 (잘못하면 그 길에 많은 고통이 있지만), 데이터 모델 추상화 등을 제공하는 데 좋습니다.
또한 뷰는 일반적으로 비즈니스 로직을 구현하는 데 사용됩니다 (과거 한 사용자는 지난 40 일 동안 로그인하지 않은 사용자입니다).
뷰는 단순히 저장되고 명명 된 SELECT 문입니다. 라이브러리 함수와 같은 뷰를 생각하십시오.
여러 UNION이 포함 된 매우 긴 SELECT를 기억합니다. 각 UNION에는 상당히 길고 이해하기 어려운 SELECT에 의해 즉석에서 생성 된 가격 테이블에 대한 조인이 포함되어 있습니다. 가격표를 만드는 관점이 있으면 좋았을 것 같습니다. 전체 SELECT를 약 절반으로 줄였습니다.
DB가 뷰를 한 번 평가할지 아니면 매번 호출 될지 모르겠습니다. 아는 사람 있어요? 전자의 경우 뷰를 사용하면 성능이 향상됩니다.
[my_interface]! = [user_interface]가 필요할 때마다.
예:
표 A :
표 A보기 :
이것은 고객에게 ID를 숨기고 정보를 한 번에 더 자세한 이름으로 바꿀 수있는 방법입니다.
뷰는 기본 키 ID에 기본 인덱스를 사용하므로 성능 손실이 발생하지 않고 선택 쿼리를 더 잘 추상화합니다.