Qual é um bom caso de uso para SELECT * no código de produção?

Eu geralmente abomino SELECT * no código de produção e já estive em uma situação em que seu uso levou a grandes quantidades de retrabalho posteriormente. No entanto, seu caso parece um uso justo.

O lugar onde acho SELECT * obrigatório - e seu primo malvado "INSERT INTO tbl" sem uma lista de colunas - está em uma situação de arquivamento, onde as linhas estão sendo movidas para outra tabela que deve ter a mesma estrutura.

INSERT INTO SalesOrderArchive  -- Note no column list
SELECT *
  FROM SalesOrder
 WHERE OrderDate < @OneYearAgo

DELETE FROM SalesOrder
 WHERE OrderDate < @OneYearAgo

Se uma nova coluna for adicionada a SalesOrder no futuro, mas não a SalesOrderArchive, o INSERT falhará. O que parece ruim, mas na verdade é uma coisa muito boa! Porque a alternativa é muito pior. Se todas as colunas estivessem listadas no INSERT e no SELECT, então o INSERT seria bem sucedido, assim como o DELETE a seguir (que é efetivamente "DELETE *"). O código de produção bem-sucedido não recebe nenhuma atenção e pode levar muito tempo até que alguém perceba que a nova coluna não está sendo arquivada, mas totalmente excluída silenciosamente.

Qual é um bom uso de select * na produção?

IMO apenas coisas assim:

por exemplo

create table #foo(a int, b int, c int, d int)
...
select * from #foo

ou

with q as
(
  select a, b, c
  from ...
)
select *
from q

ou seja, quando o *está vinculado a uma lista de colunas explícita que é declarada no mesmo lote e é usado apenas para evitar repetir a lista de colunas várias vezes.

Quando o *se refere a uma tabela ou visualização, existem algumas complexidades desagradáveis ​​sobre metadados em cache, por exemplo, aqui . E isso realmente não economiza a digitação, pois o SSMS permitirá que você arraste e solte a lista de colunas completa.

Um uso válido de SELECT *ocorre quando introduzido por EXISTS.

WHERE EXISTS (SELECT * FROM ...

Como todos os usos de SELECT *, isso tem o efeito colateral indesejado (e desnecessário aqui) de impedir que WITH SCHEMABINDINGseja adicionado se o código estiver dentro, por exemplo, de uma função.

Perguntas e respostas relacionadas: EXISTS (SELECT 1 ...) vs EXISTS (SELECT * ...) Um ou outro?

Veja também:

• Maus hábitos para chutar: usando SELECT * / omitindo a lista de colunas por Aaron Bertrand
• Quando Selecione * Não Importa por Erik Darling.

Qual é um bom uso de select * na produção?

Realmente, não há. No desenvolvimento das maneiras que você mencionou (selecione top n *), faz sentido, mas desenvolve maus hábitos e pode levar a problemas.

Você tocou no ponto principal sobre por que você não deve usá-lo, e essa é a estrutura da tabela real que pode mudar. Criar uma tabela temporária como você mencionou é tudo de bom, mas onde você pode chegar é mais tarde em seu proc, depois de preencher a tabela temporária com alguns INSERTcomandos, você retorna o conjunto de resultados com SELECT *. Agora, seu aplicativo final recuperaria colunas que não são esperadas.

Você pode usar SELECT ... INTO #TEMP FROM ...para criar a tabela temporária em tempo real também. É meio difícil saber qual é o melhor para sua situação.

A maioria dos outros problemas SELECT *não parecem importar para o seu caso de uso

• Criando uma visão (pode quebrar quando a tabela muda)
• Problemas de vinculação
• Varredura de tabela (já que você realmente deseja todas as colunas)
• Recuperando colunas desnecessárias (já que você parece querer todas elas novamente) e sua posição ordinal

Vou ser ousado e dizer: Existem casos de uso para SELECT * no código de produção. Sempre que você puder dizer "Quero que qualquer alteração na tabela seja refletida imediatamente em uma alteração na saída do meu resultado" é um caso para fazê-lo.

Deixe-me dar alguns exemplos:

Caso de uso 1 - Faça uma exibição que espelhe a tabela principal, exceto que filtra os dados corporativos confidenciais.

Nesse caso, você deseja que a exibição SELECT *. A saída deve ser um reflexo da tabela principal. Fazer com que o layout de saída corresponda ao layout da tabela é um recurso, não um bug.

...

Caso de uso 2 - Faça um proc armazenado que copie alguns registros que você está prestes a atualizar em uma tabela de retenção temporária, caso o processo apresente problemas (é meio esquisito).

Nesse caso, ter uma saída que não corresponda à tabela em si é terrível - significa que você pode não conseguir usar os dados na tabela de retenção temporária para voltar ao ponto de partida.

Minha resposta à sua pergunta é "A maioria/muitos casos de uso"

Seus casos de uso destacam por que * não é horrível. Seu esquema será alterado. Por que se preparar para tocar em cada SP porque você precisa adicionar um campo?

Se você estiver adicionando um campo, por que minha interface do usuário se importaria? Se você estiver excluindo um campo, não importa se você usa * ou um CSV, você está introduzindo uma alteração importante.

"Se o consumidor do meu procedimento armazenado for agnóstico para conjuntos de resultados dinâmicos, ..."

Aqui está o verdadeiro problema com o uso select *. Se o seu consumidor for mal escrito, você poderá ter problemas. Por exemplo, se você estiver formatando Fields[13] como uma data...

Alguns casos em que eu evitaria selecionar *:

Mitigação de latência - Meu consumidor está distante e precisa apenas de um subconjunto relativamente pequeno de campos na(s) tabela(s)

Joins - Consulta complexa envolvendo várias tabelas. O consumidor provavelmente não precisa de todos os campos de todas as tabelas. Na verdade, existem colunas de chave duplicadas que provavelmente devem ser omitidas.

Eu sei que meus consumidores escrevem código ruim - Se você estiver desenvolvendo uma API pública, suponho que seja possível que você queira honrar o OpenClose e criar um novo método de API toda vez que o conjunto de campos for alterado. Para mim, isso parece uma abordagem ruim para o referido problema ...

Como em qualquer coisa com programação, há hora e lugar. Há sempre o conjunto da torre de marfim. Ouça seus pensamentos com uma mente aberta. Então decida-se.

depende do mecanismo de falha que você preferir.

Se, quando uma nova coluna for adicionada, ela sempre puder ser ignorada com segurança (por exemplo: selecione primeiro nome, sobrenome de clientes onde id=@x), então nunca use select * - quanto mais colunas você tocar, menor a chance de um índice útil pode ser encontrado/criado.

Se quando uma nova coluna for adicionada, o descarte silencioso dela for ruim (qualquer tipo de replicação de dados), então use uma seleção não especificada (insira em archiveTable select * from theTable where isOld=true) A falha de código aqui não é um bug, é é um recurso - especialmente no caso em que você controla o banco de dados e o código lendo a tabela.

Reverter os mecanismos de falha aqui é ruim - você não quer que sua pesquisa de nome falhe se adicionar uma nova cor favorita à pessoa.

você não quer ignorar o arquivamento da cor favorita da pessoa se a coluna foi adicionada depois que você escreveu o código de arquivamento.

Uma observação sobre junções - o sql server pulará a leitura de quaisquer colunas não usadas posteriormente

select firtname,email from (select * from profile where isArchived=false)p join (select * from emailaddresses where mostRecentSend < ago(6days))e on p.id=e.profileId

não toca em nada além das colunas firstname, id e email.