Estou lendo a Bíblia do SQL Server 2008 e estou cobrindo a seção de visualizações. Mas o autor realmente não explica o propósito das visualizações. Qual é um bom uso para visualizações? Devo usá-los em meu site e quais são os benefícios deles?
Respostas:
Outro uso que nenhuma das respostas anteriores parece ter mencionado é a implementação mais fácil de mudanças na estrutura da tabela.
Digamos que você queira desativar uma tabela ( T_OLD) contendo dados para usuários ativos e, em vez disso, usar uma nova tabela com dados semelhantes (nomeados T_NEW), mas que tenha dados para usuários ativos e inativos, com uma coluna extra active.
Se o (s) seu (s) sistema (s) tem zilhões de consultas que o fazem SELECT whatever FROM T_OLD WHERE whatever, você tem duas opções para a implementação:
1) Cold Turkey - Altere o DB e, ao mesmo tempo, altere, teste e libere várias partes do código que continham a referida consulta. MUITO difícil de fazer (ou mesmo coordenar), muito arriscado. Ruim.
2) Gradual - mude o banco de dados criando a T_NEWtabela, eliminando a T_OLDtabela e, em vez disso, criando uma VIEW chamada T_OLDque imita a T_OLDtabela 100% (por exemplo, a consulta da visão é SELECT all_fields_except_active FROM T_NEW WHERE active=1).
Isso permitiria que você evitasse a liberação de QUALQUER código que atualmente selecione de T_OLDe faça as alterações para migrar o código T_OLDà T_NEWvontade.
Este é um exemplo simples, existem outros muito mais envolvidos.
PS Por outro lado, você provavelmente deveria ter uma API de procedimento armazenado em vez de consultas diretas de T_OLD, mas nem sempre é o caso.
(Copiado do primeiro tutorial que surgiu em uma pesquisa do Google (link agora morto), mas tem todos os benefícios que eu mesmo teria digitado manualmente.)
As visualizações têm os seguintes benefícios:
- Segurança - as visualizações podem ser tornadas acessíveis aos usuários, enquanto as tabelas subjacentes não estão diretamente acessíveis. Isso permite que o DBA forneça aos usuários apenas os dados de que precisam, ao mesmo tempo que protege outros dados na mesma tabela.
- Simplicidade - as visualizações podem ser usadas para ocultar e reutilizar consultas complexas.
- Simplicação ou esclarecimento do nome da coluna - as visualizações podem ser usadas para fornecer aliases nos nomes das colunas para torná-los mais memoráveis e / ou significativos.
- Stepping Stone - As visualizações podem fornecer um ponto de partida em uma consulta "multinível". Por exemplo, você pode criar uma visualização de uma consulta que contasse o número de vendas que cada vendedor realizou. Em seguida, você pode consultar essa exibição para agrupar os vendedores pelo número de vendas que realizaram.
Algumas razões da Wikipedia :
As visualizações podem oferecer vantagens sobre as tabelas:
VIEWS pode ser usado como seções reutilizáveis de SELECT / CODE, que podem ser incluídas em outros selects / queries a serem unidos, e usar vários filtros diferentes, sem ter que recriar todo o SELECT todas as vezes.
Isso também coloca a lógica em um único local, para que você não precise alterá-la em toda a base de código.
Dê uma olhada em
Escolha entre procedimentos armazenados, funções, visualizações, gatilhos, SQL embutido
A principal beleza de uma visualização é que ela pode ser usada como uma tabela na maioria das situações, mas, ao contrário de uma tabela, pode encapsular cálculos muito complexos e junções comumente usadas. Ele também pode usar praticamente qualquer objeto no banco de dados, exceto para procedimentos armazenados. As visualizações são mais úteis quando você sempre precisa juntar o mesmo conjunto de tabelas, digamos, um pedido com um detalhe do pedido para obter campos de cálculo de resumo, etc.
Uma visão é uma camada de abstração e faz o que qualquer boa camada de abstração faz, incluindo encapsular o esquema do banco de dados e protegê-lo das consequências de alterar os detalhes de implementação internos.
É uma interface.
Aqui está um uso muito comum de usar visualizações para restringir uma entidade por alguns critérios.
Tabela: USERS contém todos os usuários
Visualização: ACTIVE_USERS contém todos os usuários, exceto aqueles que estão suspensos, banidos, aguardando para serem ativados e não atendem a nenhum critério que você possa escolher definir no futuro como parte dos requisitos ativos. Isso torna desnecessário excluir quaisquer linhas da tabela USERS caso você opte por não fazê-lo, porque ACTIVE_USERS sempre pode ocultar as linhas indesejadas.
Desta forma, você pode usar a tabela em suas páginas de gerenciamento de usuário, mas o resto do aplicativo pode usar ACTIVE_USERS, pois eles podem ser os únicos usuários que devem ser capazes de executar processos e acessar / modificar dados.
As visualizações podem permitir combinar dados de várias tabelas diferentes e formatá-los (combinar campos, fornecer nomes de campo mais significativos, etc.) para que seja mais fácil para os usuários finais. Eles são uma abstração do modelo de banco de dados. Eles também podem ser usados para fornecer aos usuários acesso aos dados da tabela sem fornecer acesso direto à própria tabela.
Aqui estão algumas das muitas razões para usar view em vez de tabela diretamente
Os pontos de vista são maus! Evite-os se possível e use apenas pelo motivo mencionado por DVK - migração temporária de dados.
Você deve entender que em um banco de dados com 100 tabelas é difícil lembrar o propósito de cada tabela. Agora, se você adicionar aqui outras 300 visualizações, isso se tornará uma bagunça completa. Então, os 'amantes da visualização' tendem a usar visualizações aninhadas e, em seguida, usam as visualizações aninhadas em procedimentos armazenados. Eu pessoalmente trabalho agora com um banco de dados onde existem Views aninhadas em profundidade 4 vezes! Portanto, para entender a lógica mais simples de um procedimento armazenado, primeiro preciso passar por todas as visualizações.