Por um lado, é bom que você tenha aberto uma nova pergunta. Mas por outro lado, ao extrair uma consulta e perguntar se ela executa mais rápido, perde o contexto da pergunta anterior, a nova pergunta fica muito isolada. Como eu tenho certeza que você sabe, administrar um banco de dados, gerenciar recursos (memória/cache, disco, ciclos de CPU), gerenciar código (bom ou ruim) que usa esses recursos, fazem parte de todo o quadro. Performance é um jogo de negociação, nada é grátis.

1. 
   O principal problema que tive foi a duplicação da coluna EndDate, que é facilmente derivada. Colunas duplicadas são iguais a Atualizar Anomalias. Smirkingman forneceu o exemplo clássico:algumas consultas obterão um resultado e outras consultas obterão o outro. Isso simplesmente não é aceitável em grandes organizações; ou em bancos (pelo menos em países desenvolvidos) onde os dados são auditados e protegidos. Você violou uma regra básica de Normalização e há penalidades a serem pagas.
   
   • 
     Atualizar Anomailes; duas versões (já detalhadas). Os auditores não podem passar no sistema.
     
   • 
     Tamanho da tabela
     Em qualquer tabela grande é um problema, e especialmente em séries temporais ou dados temporais, onde o número de colunas é pequeno e o número de linhas é enorme. Então o que, alguns dirão, o espaço em disco é barato. Sim, as DSTs também. O que importa é para que é usado e como se cuida dele.
     
     • 
       Espaço em disco
       Pode ser barato em um PC, mas em um servidor de produção não é. Basicamente, você adicionou 62% ao tamanho da linha (13 mais 8 é igual a 21) e, portanto, ao tamanho da tabela. No banco que estou atualmente designado, cada departamento que possui os dados é cobrado da seguinte forma, o armazenamento baseado em SAN é tudo o que existe. Os números são por GB por mês (este não é um banco australiano de ponta):
       
       $ 1,05 para RAID5 não espelhado
       (sabemos que é lento, mas é barato, apenas não coloque informações importantes nele, porque se ele quebrar, depois que o novo disco for trocado a quente ou a frio, leva dias para para que se sincronize novamente.)
       
       $ 2,10 para RAID5 espelhado
       Na SAN, é isso.
       
       $4,40 para RAID1+0
       Mínimo para dados de produção, logs de transações com backup e dumps de banco de dados noturnos.
       
       $ 9,80 para RAID1+0 Replicado
       Para um layout SAN idêntico em outro local, à prova de bomba. Cut-over de produção em minutos; perda de transação quase zero.
       
     • 
       Memória/Cache
       Ok, o Oracle não tem, mas os bancos de dados bancários sérios têm caches, e eles são gerenciados. Dado qualquer tamanho de cache específico, apenas 62% das linhas caberão no mesmo tamanho de cache.
       
     • 
       E/S Lógica e Física
       O que significa 50% mais E/S para ler a tabela; tanto streaming em cache e leituras de disco.
       
2. 
   Portanto, se a consulta tem um desempenho melhor ou pior isoladamente, é uma questão acadêmica. No contexto acima, a tabela é lento e tem um desempenho 62% pior, o tempo todo, em todos os acessos. E está afetando todos os outros usuários no servidor. A maioria dos DBAs não se importará (eu certamente não) se o formulário de subconsulta funcionar na metade da velocidade, porque seu bônus está vinculado à aceitação da auditoria, não apenas ao desempenho do código.
   
   • 
     Além disso, há o benefício adicional de nunca ter que revisitar o código e corrigir transações devido a anomalias de atualização.
     
   • 
     E as transações têm menos pontos para atualizar, então são menores; menos bloqueios de bloqueio, etc.
     
3. 
   Concordo, essa discussão nos comentários é difícil. Na minha resposta, detalhei e expliquei duas subconsultas. Houve um mal-entendido:você estava falando sobre esta subconsulta (na cláusula WHERE, uma subconsulta de tabela ) e eu estava falando sobre a outra subconsulta (na lista de colunas, uma subconsulta escalar ) quando eu disse que funciona tão rápido ou mais rápido. Agora que isso foi esclarecido, não posso dizer que a primeira consulta acima (subconsulta na cláusula WHERE, uma tabela) funcionará tão rápido quanto a segunda consulta (com a coluna duplicada); o primeiro tem que realizar 3 scans, enquanto o segundo só faz 2 scans. (Atrevo-me a dizer que o segundo fará a varredura da tabela.)
   
   A questão é que, além da questão do isolamento, não é uma comparação justa, fiz o comentário sobre subconsultas escalares. Eu não sugeriria que uma consulta de 3 varreduras seja tão rápida ou mais rápida que uma consulta de 2 varreduras.
   
   A declaração que fiz sobre a subconsulta da tabela de 3 varreduras (que cito aqui) precisa ser tomada no contexto completo (essa postagem in toto ou a acima). Eu não estou me afastando disso.
   
   Passo metade da minha vida removendo alternativas ilegais, como colunas duplicadas, que se baseiam na questão do desempenho, com os criadores cantando o mantra da mesa é lenta, então eles "desnormalizaram para desempenho". O resultado, previsível antes de começar, é uma tabela com metade do tamanho, que funciona duas vezes mais rápido geral . A Times Series é a pergunta mais comum aqui (o link liga para outra pergunta; qual link para outra), mas imagine o problema em um banco de dados bancário:diariamente OpeningExposure e ClosingExposure por Security por Holding porUnitTrust porPortfolio .
   
4. 
   Mas deixe-me responder a uma pergunta que não foi feita. Esse tipo de interação é normal, não incomum quando se trabalha com equipes de desenvolvimento internas; surge pelo menos uma vez por mês. Um desenvolvedor crash hot já escreveu e testou seu código, usando uma tabela com coluna duplicada, ele voa, e agora está travado porque não vou colocar no db.
   
   Não, vou testá-lo no contexto de todo o sistema e:
   
   • 
     metade do tempo, a tabela vai sem a coluna EndDate porque não há grande problema em uma consulta de meio segundo agora sendo executada em um segundo.
     
   • 
     Na outra metade do tempo, o desempenho da [subconsulta da tabela] não é aceitável, então implemento um indicador booleano (bit) para identificar IsCurrent . Isso é muito melhor do que uma coluna duplicada e fornece velocidades de 2 varreduras.
     
   • 
     Nem em um milhão de anos você vai me fazer duplicar uma coluna; adicionando 62% ao tamanho da mesa; desacelerando a tabela no contexto multiusuário completo em 62%; e correm o risco de falhar em uma auditoria. E eu não sou funcionário, não recebo bônus.
     
   
   Agora valeria a pena testar:consulta com uma coluna duplicada vs consulta com um IsCurrent indicador, no contexto completo do uso geral de recursos.
   
5. 
   Smirkingman trouxe um bom ponto. E vou reafirmar isso claramente, para que não se fragmente e então um ou outro fragmento seja atacado. Por favor, não quebre isso:
   
   Um banco de dados relacional,
   normalizado por um modelador relacional experiente, para a verdadeira quinta forma normal
   (sem anomalias de atualização; sem colunas duplicadas),
   com total conformidade relacional
   (IDEF1X, particularmente relacionado à minimização de Id Chaves Primárias; e, portanto, não prejudicando o poder do mecanismo relacional)
   resultará em mais tabelas menores, um banco de dados menor,
   com menos índices,
   requerendo menos junções
   (isso mesmo, mais tabelas, mas menos junções),
   e superará qualquer coisa que viole qualquer uma dessas regras
   no mesmo hardware e empresa plataforma de banco de dados
   (exclui freeware, MS, Oracle; mas não deixe que isso o impeça),
   no contexto completo do uso de OLTP de produção
   por pelo menos uma ordem de magnitude,
   e será muito mais fácil de usar
   e alterar
   (nunca precisa de "refactoring").
   
   Já fiz isso pelo menos 80 vezes. Duas ordens de grandeza não são incomuns, se eu mesmo fizer isso, em vez de fornecer a estrutura para outra pessoa fazer isso.
   

Nem eu, nem as pessoas com quem trabalho ou que me pagam, me importo com o que uma consulta fará isoladamente.