뷰가 좋은 이유는 무엇입니까?

뷰가 좋은 이유는 무엇입니까?

---

RDBMS에서 어떤 뷰가 사용되는지에 대한 일반적인 아이디어를 얻으려고합니다. 즉, 뷰가 무엇인지, 어떻게 만드는지 압니다. 나는 또한 내가 과거에 무엇을 사용했는지 알고 있습니다.

하지만 뷰가 어떤 용도로 유용하고 어떤 용도로 유용하지 않아야하는지 철저히 이해하고 싶습니다. 더 구체적으로:

1. 보기가 유용한 이유는 무엇입니까?
   • 뷰를 사용하지 않아야 할 때 뷰를 사용하고 싶은 상황이 있습니까?
   • 테이블 반환 함수와 같은 대신 뷰를 사용하거나 그 반대로 사용하는 이유는 무엇입니까?
   • 한눈에 알 수없는 뷰가 유용 할 수있는 상황이 있습니까?

(기록을 위해 이러한 질문 중 일부는 의도적으로 순진한 것입니다. 이것은 부분적으로 개념 확인입니다.)

---

1) 뷰가 유용한 이유는 무엇입니까?

IOPO In One Place Only

• 데이터 자체를 고려하든 조인 된 테이블을 참조하는 쿼리를 고려하든 뷰를 활용하면 불필요한 중복을 피할 수 있습니다.

• 뷰는 또한 테이블에 대한 직접 액세스를 방지하는 추상화 계층을 제공합니다 (그리고 결과적으로 물리적 종속성을 참조하는 handcuffing). 사실, 나는 생각 좋은 연습 ¹ 과 같은 뷰를 포함, (뷰 및 테이블 반환 함수 사용)하여 기본 데이터 만 추상화 된 액세스를 제공하는 ¹ 내가 말한대로 나는 hafta가 할 일 "의 좋은 거래 거기 인정을,하지 I로 그 조언에 "할";)

CREATE VIEW AS
      SELECT * FROM tblData

2) 뷰를 사용하지 말아야 할 때 뷰를 사용하고 싶은 상황이 있습니까?

뷰 조인의 성능이 문제였습니다 (예 : SQL 2000). 나는 전문가는 아니지만 한동안 그것에 대해 걱정하지 않았습니다. (현재 뷰 조인을 사용하고있는 곳을 생각할 수 없습니다.)

뷰가 과도 할 수있는 또 다른 상황은 뷰가 하나의 호출 위치에서만 참조되고 파생 테이블이 대신 사용될 수있는 경우입니다. 익명 유형이 한 번만 사용 / 참조되는 경우 .NET의 클래스보다 익명 유형이 선호되는 것처럼.

    • http://msdn.microsoft.com/en-us/library/ms177634.aspx에서 파생 된 테이블 설명을 참조하십시오.

3) 테이블 반환 함수 대신 뷰를 사용하거나 그 반대의 경우 왜 사용합니까?

(성능상의 이유를 제외하고) 테이블 반환 함수는 매개 변수가있는 뷰와 기능적으로 동일합니다. 사실, 일반적인 단순 테이블 반환 함수 사용 사례는 단일 개체의 기존 뷰에 WHERE 절 필터를 추가하는 것입니다.

4) 한눈에 알 수없는 뷰가 유용 할 수있는 상황이 있습니까?

나는 내 머리 꼭대기의 명백하지 않은 사용을 생각할 수 없습니다. (내가 할 수 있다면 분명하게 만들 것이라고 생각합니다.)

---

어떤면에서 뷰는 인터페이스와 같습니다. 기본 테이블 구조를 원하는대로 변경할 수 있지만 뷰는 코드를 변경할 필요가없는 방법을 제공합니다.

보기는 보고서 작성자에게 간단한 것을 제공하는 좋은 방법입니다. 비즈니스 사용자가 Crystal Reports와 같은 데이터에 액세스하려는 경우 계정에 데이터를 단순화하는 뷰를 제공 할 수 있습니다. 심지어 비정규화할 수도 있습니다.

---

뷰를 사용하여 보안을 제공 할 수 있습니다 (예 : 사용자가 테이블의 특정 열에 만 액세스하는 뷰에 액세스 할 수 있음). 뷰는 업데이트, 삽입 등에 대한 추가 보안을 제공 할 수 있습니다. 뷰는 또한 열 이름을 별칭으로 지정하는 방법을 제공합니다. sp 's) 그러나 뷰는 실제 테이블과 더 분리되어 있습니다.

---

어떤 의미에서 뷰는 비정규 화됩니다. 더 의미있는 방식으로 데이터를 제공하려면 비정규 화가 필요한 경우가 있습니다. 이것은 많은 응용 프로그램이 객체에서 도메인 모델링을 통해 어쨌든 수행하는 작업입니다. 비즈니스 관점과보다 밀접하게 일치하는 방식으로 데이터를 제공하는 데 도움이됩니다.

---

보기는 데이터베이스 복잡성을 숨 깁니다. 여러 가지 이유로 훌륭하고 많은 상황에서 유용하지만, 자신의 쿼리 및 보고서를 작성할 수있는 사용자가있는 경우 잘못 설계된 제출을 방지하기위한 보호 수단으로 사용할 수 있습니다. 데이터베이스 서버를 다운시키는 불쾌한 데카르트 조인을 사용하는 쿼리.

---

다른 사람들이 언급 한 것 외에도 뷰는 응용 프로그램에서 더 복잡한 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 선택";

Also if the data structures ever change, you won't have to change the app code, recompile, and redeploy. you would just change the view in the db.

---

The OP asked if there were situations where it might be tempting to use a view, but it's not appropriate.

What you don't want to use a view for is a substitute for complex joins. That is, don't let your procedural programming habit of breaking a problem down into smaller pieces lead you toward using several views joined together instead of one larger join. Doing so will kill the database engine's efficiency since it's essentially doing several separate queries rather than one larger one.

For example, let's say you have to join tables A, B, C, and D together. You may be tempted to make a view out of tables A & B and a view out of C & D, then join the two views together. It's much better to just join A, B, C, and D in one query.

---

Views can centralize or consolidate data. Where I'm at we have a number of different databases on a couple different linked servers. Each database holds data for a different application. A couple of those databases hold information that are relavent to a number of different applications. What we'll do in those circumstances is create a view in that application's database that just pulls data from the database where the data is really stored, so that the queries we write don't look like they're going across different databases.

---

The responses so far are correct -- views are good for providing security, denormalization (although there is much pain down that road if done wrong), data model abstraction, etc.

In addition, views are commonly used to implement business logic (a lapsed user is a user who has not logged in in the last 40 days, that sort of thing).

---

Views save a lot of repeated complex JOIN statements in your SQL scripts. You can just encapsulate some complex JOIN in some view and call it in your SELECT statement whenever needed. This would sometimes be handy, straight forward and easier than writing out the join statements in every query.

---

A view is simply a stored, named SELECT statement. Think of views like library functions.

---

I wanted to highlight the use of views for reporting. Often, there is a conflict between normalizing the database tables to speed up performance, especially for editing and inserting data (OLTP uses), and denormalizing to reduce the number of table joins for queries for reporting and analysis (OLAP uses). Of necessity, OLTP usually wins, because data entry must have optimal performance. Creating views, then, for optimal reporting performance, can help to satisfy both classes of users (data entry and report viewers).

---

I remember a very long SELECT which involved several UNIONs. Each UNION included a join to a price table which was created on the fly by a SELECT that was itself fairly long and hard to understand. I think it would have been a good idea to have a view that to create the price table. It would have shortened the overall SELECT by about half.

I don't know if the DB would evaluate the view once, or once each time in was invoked. Anyone know? If the former, using a view would improved performance.

---

Anytime you need [my_interface] != [user_interface].

Example:

TABLE A:

• id
• info

VIEW for TABLE A:

• Customer Information

this is a way you might hide the id from the customer and rename the info to a more verbose name both at once.

The view will use underlying index for primary key id, so you won't see a performance loss, just better abstraction of the select query.

참고URL : https://stackoverflow.com/questions/214132/what-are-views-good-for