Stored Procedure vs View
18/12/2014
0
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.
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.
Randrade
Curtir tópico
+ 0
Responder
Posts
18/12/2014
Soeuseijothaz
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:
https://www.devmedia.com.br/conceitos-e-criacao-da-view-views-no-sql-server-parte-1/22390
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/
https://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.
Veja este link sobre views, acho que ajudará a clarear seu entendimento:
https://www.devmedia.com.br/conceitos-e-criacao-da-view-views-no-sql-server-parte-1/22390
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/
https://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.
Responder
18/12/2014
Fernanda Acacia
Em algumas video aulas que assisti, usa-se bastante stored procedure.
Responder
18/12/2014
Randrade
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.
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.
Responder
19/12/2014
Randrade
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.
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.
Responder
19/12/2014
Soeuseijothaz
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:
Stored precedure:
Resultado:
[img]http://arquivo.devmedia.com.br/forum/imagem/238223-20141219-101408.png[/img]
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:
Resultado:
[img]http://arquivo.devmedia.com.br/forum/imagem/238223-20141219-103205.png[/img]
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?
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:
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:
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:
[img]http://arquivo.devmedia.com.br/forum/imagem/238223-20141219-101408.png[/img]
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:
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:
[img]http://arquivo.devmedia.com.br/forum/imagem/238223-20141219-103205.png[/img]
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?
Responder
19/12/2014
Soeuseijothaz
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.
Responder
19/12/2014
Fernanda Acacia
Podemos considerar que isso é questão de gosto ou melhor, precisamente depende da situação.
Responder
19/12/2014
Soeuseijothaz
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.
Responder
Clique aqui para fazer login e interagir na Comunidade :)
