Li em algum lugar há muito tempo. O livro afirma que não devemos permitir uma exibição aninhada no SQL Server. Não tenho certeza do motivo pelo qual não podemos fazer isso ou posso me lembrar de uma declaração incorreta.
Alunos
SELECT studentID, first_name, last_name, SchoolID, ... FROM students
CREATE VIEW vw_eligible_student
AS
SELECT * FROM students
WHERE enroll_this_year = 1
Professores
SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers
CREATE VIEW vw_eligible_teacher
AS
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1
Escolas
CREATE VIEW vw_eligible_school
AS
SELECT TOP 100 PERCENT SchoolID, school_name
FROM schools sh
JOIN
vw_eligible_student s
ON s.SchoolID = sh.SchoolID
JOIN
vw_eligible_teacher t
ON s.SchoolID = t.SchoolID
No meu local de trabalho, investiguei um de nossos aplicativos de banco de dados internos. Eu verifiquei através dos objetos descobri que existem duas ou três camadas da vista empilhadas umas às outras. Então isso foi me lembrar sobre o que eu li no passado. Alguém pode ajudar a explicar?
Se não for bom fazer isso, quero saber se é limitado apenas ao SQL Server ou é para design de banco de dados em geral.
Informações Adicionais: Atualizei um exemplo da minha empresa. Eu mudo um pouco para ser mais geral sem muitos técnicos (muitas colunas neste exemplo). Principalmente a visão aninhada que usamos é baseada na visão abstrata ou agregada. Por exemplo, temos uma grande tabela de alunos com centenas de colunas. Digamos, Eligible Student Viewé baseado em alunos que se matriculam este ano. E a visualização qualificada do aluno pode ser usada em outros lugares, como no procedimento armazenado.
Independentemente da plataforma, as seguintes observações se aplicam.
(-) Visualizações aninhadas:
são mais difíceis de entender e depurar
por exemplo, a que coluna da tabela esta coluna de visão se refere? Deixe-me cavar através de 4 níveis de definições de visualização...
tornar mais difícil para o otimizador de consulta criar o plano de consulta mais eficiente
Veja isso , isso , isso e isso para evidências anedóticas. Compare com isso , que mostra que o otimizador geralmente é inteligente o suficiente para descompactar corretamente as visualizações aninhadas e selecionar um plano ideal, mas não sem um custo de compilação.
Você pode medir o custo de desempenho comparando a consulta de exibição com uma equivalente gravada nas tabelas base.
(+) Por outro lado, as visualizações aninhadas permitem:
Descobri que raramente são necessários.
No seu exemplo, você está usando visualizações aninhadas para centralizar e reutilizar determinadas definições de negócios (por exemplo, "O que é um aluno qualificado?"). Este é um uso válido para visualizações aninhadas. Se você estiver mantendo ou ajustando esse banco de dados, avalie o custo de mantê-los em relação ao custo de removê-los.
Manter: Ao manter as visualizações aninhadas, você incorre nas vantagens e desvantagens enumeradas acima.
Remover: para remover as visualizações aninhadas:
Você precisa substituir todas as ocorrências das visualizações por suas consultas básicas.
Você deve se lembrar de atualizar todas as consultas relevantes se sua definição de aluno/professor/escola elegível mudar, em vez de apenas atualizar a definição de visualização relevante.
Às vezes, visualizações aninhadas são usadas para evitar agregações repetidas. Digamos que você tenha uma visão que conta mensagens e as agrupa por ID de usuário, você pode ter uma visão que conta o número de usuários que têm > 100 mensagens, esse tipo de coisa. Isso é mais eficaz quando a exibição base é uma exibição indexada - você não necessariamente deseja criar outra exibição indexada para representar os dados com um agrupamento ligeiramente diferente, porque agora você está pagando pela manutenção do índice duas vezes, onde o desempenho provavelmente é adequado contra a visão original.
Se todas essas são apenas exibições aninhadas em que você está selecionando *, mas alterando a ordem ou a parte superior, parece que isso seria melhor encapsulado como um procedimento armazenado com parâmetros (ou funções com valor de tabela em linha) do que várias exibições aninhadas. NA MINHA HUMILDE OPINIÃO.
Versões posteriores do SQL (2005+) parecem melhores para otimizar o uso de visualizações. As visualizações são melhores para consolidar regras de negócios. EG: onde eu trabalho temos um banco de dados de produtos de telecomunicações. Cada produto é atribuído a um plano de tarifas, e esse plano de tarifas pode ser trocado, e as tarifas do plano de tarifas podem ser ativadas/desativadas à medida que as tarifas são aumentadas ou modificadas.
Para facilitar, podemos criar visualizações aninhadas. A 1ª visualização apenas une os planos de taxas às suas taxas usando quaisquer tabelas necessárias e retornando quaisquer dados necessários que os próximos níveis de visualizações precisariam. A(s) segunda(s) visualização(ões) pode(m) isolar apenas planos de tarifas ativos e suas tarifas ativas. Ou, apenas taxas de cliente. Ou taxas de funcionários (para desconto de funcionários). Ou taxas de clientes comerciais versus residenciais. (tarifários podem ficar complicados). O ponto é que a visão de base garante que nossa lógica geral de negócios para planos de tarifas e tarifas sejam unidas adequadamente em um único local. A próxima camada de visualizações nos dá mais foco em planos de taxas específicos (tipos, ativo/inativo, etc).
Concordo que as visualizações podem tornar a depuração confusa se você estiver criando consultas e visualizações ao mesmo tempo. Mas, se você estiver usando uma visualização testada e confiável, a depuração será mais fácil. Você sabe que a visualização já passou pela campainha, então você sabe que provavelmente não está causando o problema.
Problemas podem surgir com seus pontos de vista, no entanto. "e se um produto estiver associado apenas a um plano de tarifas inativo?" ou "e se um plano de tarifas tiver apenas tarifas inativas?" Bem, isso pode ser pego no nível de front-end com lógica que detecta erros do usuário. "Erro, o produto está em um plano de tarifas inativo... corrija". Também podemos executar auditorias de consulta para verificar novamente antes de uma execução de cobrança. (selecione todos os planos e vá para a visualização do plano de tarifas ativo, apenas devolva os planos que não recebem um plano de tarifas ativo como problemas que precisam ser resolvidos).
O bom disso é que as visualizações permitem que você condense bastante as consultas para relatórios, cobrança etc. Você pode ter uma visualização da conta do cliente e, em seguida, uma visualização de segundo nível apenas dos clientes ativos. Equipe isso com uma visão do endereço do cliente. Equipe isso com uma visão do(s) produto(s) (juntou-se sobre qual(is) produto(s) o cliente possui). Equipe que para visualizar o plano de tarifas do(s) produto(s). Equipe isso com visão dos recursos do produto. Ver, ver, ver, cada tentativa e erro para garantir a integridade. Sua consulta final usando as visualizações é muito compacta.
editar:
Como um exemplo de como a visualização teria sido melhor do que apenas uma consulta simples de tabelas... nós tivemos um contratado temporário para fazer algumas mudanças. Disseram-lhe que havia pontos de vista para as coisas, mas ele decidiu achatar todas as suas perguntas. O faturamento estava executando algumas de suas consultas. Eles continuaram recebendo vários planos de taxas e taxas sobre as coisas. Acontece que suas consultas estavam faltando critérios para permitir que as taxas fossem cobradas apenas se estivessem entre as datas de início e término em que o plano de tarifas deveria usar isso / essas taxas durante. Ops. Se ele tivesse usado a visão, já teria levado essa lógica em consideração.
Basicamente, você tem que pesar desempenho versus sanidade. Talvez você possa fazer todos os tipos de coisas extravagantes para aumentar o desempenho de um banco de dados. Mas, se isso significa que é um pesadelo para uma nova pessoa assumir / manter, realmente vale a pena? Será que realmente vale a pena o cara novo ter que jogar o whack-a-mole ter que encontrar todas as consultas que precisam mudar sua lógica (e arriscar ele esquecê-los / dedilhados) porque alguém decidiu que as visualizações são "ruins" e não consolidou alguma lógica de negócios principal em uma que pudesse ser usada em centenas de outras consultas? Depende muito do seu negócio e da sua equipe de TI/IS/DB. Mas, prefiro clareza e consolidação de fonte única em vez de desempenho.
A verdadeira questão não são as visões aninhadas em si mesmas. O verdadeiro problema é a proliferação de visualizações aninhadas à medida que os desenvolvedores colocam ajustes adicionais nas visualizações existentes. Eu encontrei consultas com uma visão aninhada de 4 camadas que realmente se juntaram a uma das visualizações em sua definição. Nossa tendência a tomar o caminho mais fácil em vez de analisar e resolver um problema é a raiz do problema.
No meu ambiente, replicamos muitas tabelas do servidor de produção para o servidor de relatórios. No servidor de relatórios, temos muitas visualizações baseadas em tabelas de produção replicadas E estão aninhadas. Antes de iniciar a replicação, temos que remover todas as visualizações para possibilitar a replicação (usamos soltar e criar porque a estrutura das tabelas geralmente muda na produção). Após o término da replicação, temos que reconstruir todas as visualizações.
Agora, aqui está a parte divertida: como muitas das visualizações são aninhadas, temos que reconstruí-las em uma ordem específica. Ao fazer qualquer alteração na definição de visualizações, devemos prestar atenção para manter a ordem correta de reconstrução. É uma bagunça total. Eu desencorajo fortemente o uso de exibições aninhadas se você usar replicação ou simplesmente descartar e reconstruir suas tabelas, que são a origem das exibições.
Desempenho é outra coisa. As exibições baseadas em outras exibições nada mais são do que várias consultas a serem executadas. É mais fácil reunir a consulta maior, criar um trabalho e fazer uma tabela a partir dele. Mais fácil e melhora o desempenho.