Array
(
)

Stored Procedure vs View

Randrade
   - 18 dez 2014

Olá pessoa,
Estou desenvolvendo uma aplicação, onde já possui um banco de dados criado e povoado. Não tenho acesso a ele diretamente, mas tenho a possibilidade de trabalhar com uma view ou uma Stored Prodedure. Gostaria de saber qual seria o modo mais fácil e mais eficaz de trabalhar com o banco.
O banco é em Sql Server 2008, e estou desenvolvendo em ASp.NET MVC 5.

Jothaz
   - 18 dez 2014

Como tudo na informática depende do cenário, pois são coisas distintas e que até podem ser utilizadas em conjunto.

Veja este link sobre views, acho que ajudará a clarear seu entendimento:
http://www.devmedia.com.br/introducao-as-stored-procedure-com-sql-server-2000-2005/2213

No próximos link´s um post sobre Stored procedures e sobre Stored procedures vs views:

http://imasters.com.br/artigo/223/sql-server/criacao-e-uso-de-stored-procedures/

http://www.devmedia.com.br/introducao-as-stored-procedure-com-sql-server-2000-2005/2213

É mais produtivo lhe passar os link e depois você vir sanar sua dúvidas ou complementar o entendimento.

Qualquer coisa estamos ai.

Fernanda Acacia
   - 18 dez 2014

Em algumas video aulas que assisti, usa-se bastante stored procedure.

Jothaz
   - 18 dez 2014


Citação:
Em algumas video aulas que assisti, usa-se bastante stored procedure.


Normalmente usá-se as stored procedures, pois com elas é possível executar diversas ações no banco. São procedimentos como select, update, delete e abrir cursores. Generalizando stored procedures é uma programação onde executam-se ações e pode ou não retornar um conjunto de dados.

As views são "visões" lógicas de dados das tabelas físicas. Nelas é possível a junção de dados de uma ou mais tabelas, com o intuito de agrupar ou filtrar os dados. Você pode executar select´s além de usar whre e order by usando uma view. E claro você pode usá-las em stored procedures.

Criando uma view, note-se que nesta view só retornaram os registros em que o campo Discontinued=0 :

#Código

create view [dbo].[Alphabetical list of products] AS
SELECT Products.*, Categories.CategoryName
FROM Categories INNER JOIN Products ON Categories.CategoryID = Products.CategoryID
WHERE (((Products.Discontinued)=0))


Usando s view:

#Código
SELECT *
  FROM [dbo].[Alphabetical list of products]


Ou (no comando a seguir na verdade esta sendo executados dois filtros. O filtro da view Discontinued=0 e o filtro CategoryName like 'bev%' )

#Código
SELECT *
  FROM [dbo].[Alphabetical list of products]
  where CategoryName like 'bev%'

Randrade
   - 18 dez 2014

Valeu Jothaz,

Olhei os links que você me passou, e com essa explicação você terminou de esclarecer minhas dúvidas.

Neste caso, especificamente, uma view irá me atender melhor.

Fernanda Acacia
   - 18 dez 2014

Por quais motivos considera a view melhor?

Randrade
   - 19 dez 2014

Neste caso, especificamente, necessitarei apenas retornar alguns valores do banco, para exibição.

E nos artigos que li, apontaram que a Stored Procedure aloca um pequeno espaço de memória no banco, enquanto a view trabalha como uma tabela virtual, sendo assim, retornando os dados mais rápidos( dependendo da estrutura e de como é montada).
E conversando com o DBA, ele me informou a mesma coisa.

Porém, existe uma discussão eterna sobre este assunto, então optei pela view. Porém irei ler mais e tirar minhas próprias conclusões, no futuro.

Jothaz
   - 19 dez 2014

Randrade,

Só um lembrete, no caso de qualquer mudança estrutural nas tabelas que compõem a view renomear campos, excluir campos (claro somente os que fazem parte da view)
ou adicionar campos que devam aparecer na view, você precisa recriá-la manualmente.

Fernanda,

Como o RANDRADE ressaltou existe uma discussão acalorada e sem fim sobre o que seria mais indicado usar: views ou stored procedures.
Isto ocorre porque em alguns casos com as duas abordagens pode-se obter os mesmos resultados, gerando confusão.

Veja nos exemplos a seguir que o resultado da execução será o mesmo tanto usando a stored procedure quanto a view.

View:

#Código

CREATE VIEW [SalesLT].[View_ProductAndDescription] 
WITH SCHEMABINDING 
AS 
SELECT 
    p.[ProductID] 
	,p.[ProductCategoryID]
    ,p.[Name] 
    ,pm.[Name] AS [ProductModel] 
    ,pmx.[Culture] 
    ,pd.[Description] 
FROM [SalesLT].[Product] p 
    INNER JOIN [SalesLT].[ProductModel] pm 
    ON p.[ProductModelID] = pm.[ProductModelID] 
    INNER JOIN [SalesLT].[ProductModelProductDescription] pmx 
    ON pm.[ProductModelID] = pmx.[ProductModelID] 
    INNER JOIN [SalesLT].[ProductDescription] pd 
    ON pmx.[ProductDescriptionID] = pd.[ProductDescriptionID]
WHERE [SellEndDate] is  null;
GO


Stored precedure:

#Código
CREATE PROCEDURE [dbo].[sp_ProductAndDescription] 
AS                              
BEGIN
SELECT 
    p.[ProductID] 
	,p.[ProductCategoryID]
    ,p.[Name] 
    ,pm.[Name] AS [ProductModel] 
    ,pmx.[Culture] 
    ,pd.[Description] 
FROM [SalesLT].[Product] p 
    INNER JOIN [SalesLT].[ProductModel] pm 
    ON p.[ProductModelID] = pm.[ProductModelID] 
    INNER JOIN [SalesLT].[ProductModelProductDescription] pmx 
    ON pm.[ProductModelID] = pmx.[ProductModelID] 
    INNER JOIN [SalesLT].[ProductDescription] pd 
    ON pmx.[ProductDescriptionID] = pd.[ProductDescriptionID]
WHERE [SellEndDate] is  null
END;
GO


Resultado:

Clique na imagem para abrir em uma nova janela

Então qual usar?
A resposta, que parece clichê, é depende do cenário. Se o resultado for utilizado em apenas uma pesquisa na aplicação então o mais indicado é usar a stored procedure, porém se este resultado for usado em vários locais e usado em muitas oportunidades o indicado seria a view. Digo indicado não correto, pois vai da interpretação e do gosto de cada um.

No caso a view pode ser utilizada dentro de uma stored procedure ou mesmo em conjunto com outras tabelas através de select, joins e where. Já a sotred procedure não teria esta flexibilidade, após ser executada ela retorna o conjunto de dados e pronto. A view fica salva e pode ser usado de várias formas diferentes como no exemplo abaixo:

#Código
SELECT	v.[ProductID] 
		,v.[Name] 'Nome Produto'
		,c.Name 'Nome Categoria'
		,v.Culture
FROM	SALESLT.VIEW_PRODUCTANDDESCRIPTION V
		INNER JOIN SALESLT.PRODUCTCATEGORY C  
		ON V.PRODUCTCATEGORYID = C.PRODUCTCATEGORYID
WHERE v.Culture = 'en'


Resultado:

Clique na imagem para abrir em uma nova janela

Note no select não precisei fazer os joins com ProductModel, ProductModelProductDescription, ProductDescription, alem de que sempre se utilizar a view somente serão retornados registros em que SellEndDate é diferente de nulo ([SellEndDate] is null) istgo esta encapsulado na view. E no select acima ainda inclui outro filtro WHERE v.Culture = 'en'. Isto não teria como ser feito com a stored procedure.

Então existem ações que podemos efetuar com a view que não é possível executar com a stored procedure e vice versa. Pois se você precisar efetuar vários processos e atualizações condicionais só poderá fazê-lo com sotred procedure. Sendo bem simplista a stored procedure são como programas que você faria em qualquer linguagem, só que atuando no banco de dados. A view é como se você salvasse a execução de um select e pudesse usá-lo posteriormente.

Cada um tem suas vantagens no caso das view podem ser mais rápidas, pois podemos indexá-las e consume menos memória. As stored procedures tem uma amplitude maior possibilitando um uso em vários casos, portanto na maioria das vezes será utilizada.

Então qual usar? Isso vai dos requisitos, do entendimento do cenário, da vivência e do gosto pessoal do projetista. Só você enquanto o construtor da solução poderá e deverá ter os subsídios para definir qual solução adotar.

Deu uma luz ou escureceu de vez?

Eduardo
   - 19 dez 2014

Store procedure que eu saiba é mais rápida do que view

Jothaz
   - 19 dez 2014


Citação:
Store procedure que eu saiba é mais rápida do que view


Normalmente acredito que sp´s são mais rápidas.

Nunca fiz nenhum benchmark, mas acredito que se indexadas a views podem ser mais rápidas, então para quem quer ser mais minucioso é só testar.

Deve-se levar em consideração que mesmo que a as stored procedures possam obter o mesmo resultado que as views não tem como usá-las posteriormente usando select´s, filtros e ordenação. Então a perda de performance, desde que tolerável, pode ser compensada pela flexibilidade da view.

Então são universos e usos diferentes.

Mas como ressaltei em todo o post depende do cenário e vai da preferência de cada um e as vezes a diferença de performance, "dependendo do cenário" é desprezível.

E claro que não se pode substituir sempre a stored procedures por views.

Fernanda Acacia
   - 19 dez 2014

Podemos considerar que isso é questão de gosto ou melhor, precisamente depende da situação.

Jothaz
   - 19 dez 2014


Citação:
Podemos considerar que isso é questão de gosto ou melhor, precisamente depende da situação.


Sempre depende da situação!

Se após analisar chegar-se a conclusão que ambos vão chegar ao mesmo resultado e terão a mesma usabilidade, ai é vai da maturidade, vivência e do gosto pessoal.

Pois mesmo que você tenho uma preferência por views na maioria das vezes não poderá implementá-las, pois esta fora do escopo da mesma.
Exemplo processar vários registros, atualizar , e excluir registros de várias tabelas de acordo o processamento não teria como ser feito por view. Um CRUD ou se faz via expressão sql ou stored procedure.

A view ´s para facilitar/otimizar o acesso a dados. É com se fosse a junção de várias tabela em um terceira tabela que não esta gravada fisicamente no banco de dados.
É uma "visão" lógica de dados físicos.