저장 프로 시저와 뷰의 차이점은 무엇입니까?

저장 프로 시저와 뷰의 차이점은 무엇입니까?

---

몇 가지 점에 대해 혼란 스럽습니다.

1. 저장 프로 시저와 뷰의 차이점은 무엇입니까?

2. SQL Server에서 언제 저장 프로 시저를 사용하고 언제 뷰를 사용해야합니까?

3. 뷰를 통해 매개 변수를 전달할 수있는 동적 쿼리를 작성할 수 있습니까?

4. 어느 것이 가장 빠르며 어떤 기준이 다른 것보다 빠릅니까?

5. 뷰 또는 저장 프로 시저가 메모리를 영구적으로 할당합니까?

6. 누군가가 뷰가 가상 테이블을 생성하고 절차가 재료 테이블을 생성한다고 말하는 것은 무엇을 의미합니까?

더 많은 포인트가 있으면 알려주세요.

---

뷰는 가상 테이블을 나타냅니다 . 뷰에서 여러 테이블을 조인하고 뷰를 사용하여 데이터가 단일 테이블에서 온 것처럼 데이터를 표시 할 수 있습니다.

저장 프로시 저는 매개 변수를 사용하여 데이터를 업데이트 및 삽입하거나 단일 값 또는 데이터 세트를 반환하는지 여부에 관계없이 함수를 수행합니다.

뷰 및 저장 프로 시저 만들기 -각각의 사용시기와 이유에 대한 Microsoft의 정보가 있습니다.

두 개의 테이블이 있다고 가정 해보십시오.

tbl_user 열 : .user_id, .user_name, .user_pw

tbl_profile 열 : .profile_id, .user_id .profile_description

그래서 내가 그 테이블에서 많이 쿼리하는 것을 발견하면 ... SQL의 모든 조각에서 조인을 수행하는 대신 다음과 같은 뷰를 정의합니다.

CREATE View vw_user_profile
AS
  Select A.user_id, B.profile_description
  FROM tbl_user A left join tbl_profile B on A.user_id = b.user_id
GO

그래서 나중에 사용자 ID로 profile_description을 쿼리하려면 ...해야 할 일은

SELECT profile_description FROM vw_user_profile WHERE user_id = @ID

해당 코드는 다음과 같은 저장 프로 시저에서 사용될 수 있습니다.

create procedure dbo.getDesc
 @ID int
AS
begin
SELECT profile_description FROM vw_user_profile WHERE user_id = @ID
END
GO

나중에 전화 할 수 있습니다

dbo.getDesc 25

사용자 ID 25에 대한 설명을 얻습니다. 여기서 25는 매개 변수입니다.

분명히 더 많은 세부 사항이 있지만 이것은 기본 아이디어 일뿐입니다.

---

많은 정보가 여기에 있습니다

다음은 좋은 요약입니다.

저장 프로 시저 :

• 매개 변수를 받아들입니다
• 더 큰 쿼리에서 빌딩 블록으로 사용할 수 없습니다
• 여러 명령문, 루프, IF ELSE 등을 포함 할 수 있습니다.
• 하나 또는 여러 테이블을 수정할 수 있습니다
• INSERT, UPDATE 또는 DELETE 문의 대상으로 사용할 수 없습니다.

관점:

• 않습니다 NOT 매개 변수를 허용
• 더 큰 쿼리에서 빌딩 블록으로 사용할 수 있습니다
• 하나의 SELECT 쿼리 만 포함 할 수 있습니다
• 테이블을 수정할 수 없습니다
• 그러나 INSERT, UPDATE 또는 DELETE 문의 대상으로 (때로는) 사용할 수 있습니다.

---

먼저 이해해야합니다. 둘 다 다릅니다. 저장 프로시 저는 INSERT-UPDATE-DELETE 문에 가장 적합합니다. 및 뷰는 SELECT 문에 사용됩니다. 둘 다 사용해야합니다.

뷰에서는 데이터를 변경할 수 없습니다. 일부 데이터베이스에는 뷰에 INSERT-UPDATE-DELETE를 사용할 수있는 업데이트 가능한 뷰가 있습니다.

---

뷰는 SELECT데이터베이스에 컴플렉스를 저장하는 간단한 방법 입니다.

단순한 SQL로 충분하지 않은 경우 저장 프로 시저가 사용됩니다. 저장 프로 시저에는 변수, 루프 및 다른 저장 프로 시저에 대한 호출이 포함됩니다. 쿼리 언어가 아닌 프로그래밍 언어입니다.

1. Views are static. Think of them as new tables with a certain layout and the data in them is created on the fly using the query you created it with. As with any SQL table, you can sort and filter it with WHERE, GROUP BY and ORDER BY.

2. The depends on what you do.

3. The depends on the database. Simple views just run the query and filter the result. But databases like Oracle allow to create a "materialized" view which is basically a table which is updated automatically when the underlying data of the view changes.

   A materialized view allows you to create indexes on the columns of the view (especially on the computed columns which don't exist anywhere in the database).

4. I don't understand what you're talking about.

---

A SQL View is a virtual table, which is based on SQL SELECT query. A view references one or more existing database tables or other views. It is the snap shot of the database whereas a stored procedure is a group of Transact-SQL statements compiled into a single execution plan.

View is simple showcasing data stored in the database tables whereas a stored procedure is a group of statements that can be executed.

A view is faster as it displays data from the tables referenced whereas a store procedure executes sql statements.

Check this article : View vs Stored Procedures . Exactly what you are looking for

---

1. A VIEW is a dynamic query where you can use a "WHERE"-Clause
2. A stored procedure is a fixed data selection, which returns a predefined result
3. Nor a view, nor a stored procedure allocate memory. Only a materialized view
4. A TABLE is just one ENTITY, a view can collect data from different ENTITIES or TABLES

---

Main difference is that when you are querying a view then it's definition is pasted into your query. Procedure could also give results of query, but it is compiled and for so faster. Another option are indexed views..

---

Mahesh is not quite correct when he suggests that you can't alter the data in a view. So with patrick's view

CREATE View vw_user_profile AS 
Select A.user_id, B.profile_description
FROM tbl_user A left join tbl_profile B on A.user_id = b.user_id

I CAN update the data ... as an example I can do either of these ...

Update vw_user_profile Set profile_description='Manager' where user_id=4

or

Update tbl_profile Set profile_description='Manager' where user_id=4

You can't INSERT to this view as not all of the fields in all of the table are present and I'm assuming that PROFILE_ID is the primary key and can't be NULL. However you can sometimes INSERT into a view ...

I created a view on an existing table using ...

Create View Junk as SELECT * from [TableName]

THEN

Insert into junk (Code,name) values 
('glyn','Glyn Roberts'),
('Mary','Maryann Roberts')

and

DELETE from Junk Where ID>4

Both the INSERT and the DELETE worked in this case

Obviously you can't update any fields which are aggregated or calculated but any view which is just a straight view should be updateable.

If the view contains more than one table then you can't insert or delete but if the view is a subset of one table only then you usually can.

---

In addition to the above comments, I would like to add few points about Views.

1. Views can be used to hide complexity. Imagine a scenario where 5 people are working on a project but only one of them is too good with database stuff like complex joins. In such scenario, he can create Views which can be easily queried by other team members as they are querying any single table.
2. Security can be easily implemented by Views. Suppose we a Table Employee which contains sensitive columns like Salary, SSN number. These columns are not supposed to be visible to the users who are not authorized to view them. In such case, we can create a View selecting the columns in a table which doesn't require any authorization like Name, Age etc, without exposing sensitive columns (like Salary etc. we mentioned before). Now we can remove permission to directly query the table Employee and just keep the read permission on the View. In this way, we can implement security using Views.

---

@Patrick is correct with what he said, but to answer your other questions a View will create itself in Memory, and depending on the type of Joins, Data and if there is any aggregation done, it could be a quite memory hungry View.

Stored procedures do all their processing either using Temp Hash Table e.g #tmpTable1 or in memory using @tmpTable1. Depending on what you want to tell it to do.

A Stored Procedure is like a Function, but is called Directly by its name. instead of Functions which are actually used inside a query itself.

Obviously most of the time Memory tables are faster, if you are not retrieveing alot of data.

참고URL : https://stackoverflow.com/questions/5194995/what-is-the-difference-between-a-stored-procedure-and-a-view