it-swarm-pt.tech

Qual é o mais rápido / melhor? SELECT * ou SELECT coluna1, coluna2, coluna3, etc

Ouvi dizer que SELECT * geralmente é uma má prática para escrever comandos SQL, porque é mais eficiente para SELECT colunas de que você precisa especificamente.

Se eu precisar SELECT todas as colunas da tabela, devo usar

SELECT * FROM TABLE

ou

SELECT column1, colum2, column3, etc. FROM TABLE

A eficiência realmente importa nesse caso? Eu acho que SELECT * seria mais ideal internamente se você realmente precisar de todos os dados, mas estou dizendo isso sem um entendimento real do banco de dados.

Estou curioso para saber qual é a melhor prática neste caso.

PDATE: Eu provavelmente deveria especificar que a única situação em que eu realmente gostaria de fazer um SELECT * é quando Estou selecionando dados de uma tabela em que sei que todas as colunas sempre precisam ser recuperadas, mesmo quando novas colunas são adicionadas.

Dadas as respostas que eu vi no entanto, isso ainda parece uma péssima idéia e SELECT * nunca deve ser usado por razões muito mais técnicas que eu já pensei.

155
Dan Herbert

Um motivo pelo qual a seleção de colunas específicas é melhor é o fato de aumentar a probabilidade de o SQL Server acessar os dados dos índices, em vez de consultar os dados da tabela.

Aqui está um post que escrevi sobre o assunto: A verdadeira razão pela qual as consultas de seleção são uma cobertura ruim do índice

Também é menos frágil alterar, pois qualquer código que consome os dados terá a mesma estrutura de dados, independentemente das alterações feitas no esquema da tabela no futuro.

158
Jon Galloway

Dada a especificação sua que você está selecionando todas as colunas, há pouca diferença no momento. Perceba, no entanto, que os esquemas do banco de dados mudam. Se você usar SELECT *, todas as novas colunas serão adicionadas à tabela, mesmo que com toda a probabilidade, seu código não esteja preparado para usar ou apresentar esses novos dados. Isso significa que você está expondo seu sistema a alterações inesperadas de desempenho e funcionalidade.

Você pode descartar isso como um custo menor, mas saiba que as colunas que você não precisa ainda devem ser:

  1. Ler do banco de dados
  2. Enviado pela rede
  3. Marshalled em seu processo
  4. (para tecnologias do tipo ADO) Salvas em uma memória de tabela de dados
  5. Ignorado e descartado/coletado de lixo

O item 1 tem muitos custos ocultos, incluindo a eliminação de algum índice de cobertura em potencial, causando carregamentos da página de dados (e debulha do cache do servidor), incorrendo em bloqueios de linha/página/tabela que, de outra forma, poderiam ser evitados.

Equilibre isso com as economias em potencial de especificar as colunas versus um * e as únicas economias em potencial são:

  1. O programador não precisa revisitar o SQL para adicionar colunas
  2. O transporte de rede do SQL é menor/mais rápido
  3. Tempo de análise/validação de consulta do SQL Server
  4. Cache do plano de consulta do SQL Server

Para o item 1, a realidade é que você adicionará/alterará o código para usar qualquer nova coluna que possa adicionar de qualquer maneira, portanto é uma lavagem.

Para o item 2, a diferença raramente é suficiente para levar você a um tamanho ou número de pacotes de rede diferente. Se você chegar ao ponto em que o tempo de transmissão da instrução SQL é o problema predominante, provavelmente precisará reduzir a taxa de instruções primeiro.

Para o item 3, NÃO há economia, pois a expansão do * deve ocorrer de qualquer maneira, o que significa consultar o esquema da tabela (s) de qualquer maneira. Realisticamente, a listagem das colunas incorrerá no mesmo custo, pois elas precisam ser validadas com relação ao esquema. Em outras palavras, esta é uma lavagem completa.

Para o item 4, quando você especifica colunas específicas, o cache do plano de consulta pode ficar maior, mas apenas se você estiver lidando com conjuntos diferentes de colunas (que não é o que você especificou). Nesse caso, você deseja entradas de cache diferentes porque deseja planos diferentes, conforme necessário.

Portanto, tudo se resume, por causa da maneira como você especificou a pergunta, à resiliência do problema diante de eventuais modificações de esquema. Se você estiver gravando esse esquema em ROM (acontece), um * será perfeitamente aceitável.

No entanto, minha orientação geral é que você deve selecionar apenas as colunas necessárias, o que significa que às vezes parecerá que você está solicitando todas elas, mas os DBAs e a evolução do esquema significam que algumas novas colunas podem parece que poderia afetar bastante a consulta.

Meu conselho é que você deve SEMPRE SELECIONE colunas específicas. Lembre-se de que você é bom no que faz repetidas vezes, então adquira o hábito de fazer o que é certo.

Se você está se perguntando por que um esquema pode mudar sem alterar o código, pense em termos de log de auditoria, datas de validade/validade e outras coisas semelhantes que são adicionadas pelos DBAs para problemas sistemáticos de conformidade. Outra fonte de alterações ocultas são as desnormalizações para desempenho em outras partes do sistema ou nos campos definidos pelo usuário.

57
IDisposable

Você deve selecionar apenas as colunas necessárias. Mesmo se você precisar de todas as colunas, ainda é melhor listar os nomes das colunas para que o servidor sql não precise consultar colunas na tabela do sistema.

Além disso, seu aplicativo pode ser interrompido se alguém adicionar colunas à tabela. Seu programa também receberá colunas que não esperava e talvez não saiba como processá-las.

Além disso, se a tabela tiver uma coluna binária, a consulta será muito mais lenta e usará mais recursos de rede.

33
Giorgi

Há quatro grandes razões para que select * seja uma coisa ruim:

  1. O motivo prático mais significativo é que ele força o usuário a saber magicamente a ordem na qual as colunas serão retornadas. É melhor ser explícito, o que também protege você contra a alteração da tabela, que segue muito bem ...

  2. Se um nome de coluna que você está usando for alterado, é melhor identificá-lo mais cedo (no momento da chamada SQL) do que quando você estiver tentando usar a coluna que não existe mais (ou teve seu nome alterado etc.) )

  3. A listagem dos nomes das colunas torna seu código muito mais auto-documentado e, portanto, provavelmente mais legível.

  4. Se você estiver transferindo por uma rede (ou mesmo se não estiver), as colunas que você não precisa são apenas desperdício.

30
pkh

Especificar a lista de colunas é geralmente a melhor opção, porque seu aplicativo não será afetado se alguém adicionar/inserir uma coluna na tabela.

9
ilitirit

A especificação dos nomes das colunas é definitivamente mais rápida - para o servidor. Mas se

  1. desempenho não é um grande problema (por exemplo, este é um banco de dados de conteúdo de sites com centenas, talvez milhares - mas não milhões - de linhas em cada tabela); E
  2. seu trabalho é criar muitos aplicativos pequenos e similares (por exemplo, sites gerenciados por conteúdo voltados para o público) usando uma estrutura comum, em vez de criar um aplicativo único e complexo; E
  3. a flexibilidade é importante (muita personalização do esquema db para cada site);

então é melhor ficar com SELECT *. Em nossa estrutura, o uso intenso de SELECT * nos permite introduzir um novo campo de conteúdo gerenciado por site em uma tabela, oferecendo todos os benefícios do CMS (controle de versão, fluxo de trabalho/aprovações etc.), enquanto apenas tocamos o código de uma vez. alguns pontos, em vez de algumas dúzias de pontos.

Eu sei que os gurus do banco de dados vão me odiar por isso - vá em frente, vote em mim - mas no meu mundo, o tempo do desenvolvedor é escasso e os ciclos de CPU são abundantes, então eu ajusto de acordo o que economizo e o que desperdiço.

7
Herb Caudill

SELECT * é uma prática ruim, mesmo que a consulta não seja enviada por uma rede.

  1. Selecionar mais dados do que o necessário torna a consulta menos eficiente - o servidor precisa ler e transferir dados extras, o que leva tempo e cria uma carga desnecessária no sistema (não apenas na rede, como outros mencionados, mas também em disco, CPU etc. ) Além disso, o servidor não pode otimizar a consulta da melhor maneira possível (por exemplo, use o índice de cobertura da consulta).
  2. Depois de algum tempo, a estrutura da tabela pode mudar, então SELECT * retornará um conjunto diferente de colunas. Portanto, seu aplicativo pode obter um conjunto de dados de estrutura inesperada e quebrar em algum ponto a jusante. A indicação explícita das colunas garante que você obtenha um conjunto de dados de estrutura conhecida ou obtenha um erro claro no nível do banco de dados (como 'coluna não encontrada').

Obviamente, tudo isso não importa muito para um sistema pequeno e simples.

6
VladV

Em termos de desempenho, o SELECT com colunas específicas pode ser mais rápido (não é necessário ler todos os dados). Se sua consulta realmente usar TODAS as colunas, SELECT com parâmetros explícitos ainda será o preferido. Qualquer diferença de velocidade será basicamente imperceptível e quase em tempo constante. Um dia seu esquema será alterado, e este é um bom seguro para evitar problemas devido a isso.

4
Yann Ramin

Muitas boas razões respondidas aqui até agora, aqui está outra que não foi mencionada.

Nomear explicitamente as colunas ajudará na manutenção no futuro. Em algum momento, você fará alterações ou solução de problemas e se perguntará "onde diabos é essa coluna usada".

Se você tiver os nomes listados explicitamente, encontrar todas as referências a essa coluna - através de todos os seus procedimentos armazenados, visualizações etc. - é simples. Apenas despeje um script CREATE para o seu esquema de banco de dados e pesquise por texto nele.

4
Chris Wuestefeld

Você realmente deve selecionar apenas os campos necessários e apenas o número necessário, ou seja,.

SELECT Field1, Field2 FROM SomeTable WHERE --(constraints)

Fora do banco de dados, as consultas dinâmicas correm o risco de ataques de injeção e dados malformados. Normalmente, você contorna isso usando procedimentos armazenados ou consultas parametrizadas. Além disso (embora não seja realmente um problema), o servidor precisa gerar um plano de execução sempre que uma consulta dinâmica é executada.

4
Matthew Abbott

O problema com "select *" é a possibilidade de trazer dados que você realmente não precisa. Durante a consulta real ao banco de dados, as colunas selecionadas não são realmente adicionadas ao cálculo. O que é realmente "pesado" é o transporte de dados de volta ao seu cliente, e qualquer coluna que você realmente não precisa está apenas desperdiçando largura de banda da rede e aumentando o tempo que você está esperando pela consulta retornar.

Mesmo se você usar todas as colunas trazidas de um "select * ...", isso é apenas por enquanto. Se, no futuro, você alterar o layout da tabela/exibição e adicionar mais colunas, você começará a selecioná-las, mesmo que não precise delas.

Outro ponto em que uma instrução "select *" é inválida está na criação da exibição. Se você criar uma visualização usando "select *" e posteriormente adicionar colunas à sua tabela, a definição da visualização e os dados retornados não corresponderão e será necessário recompilar suas visualizações para que funcionem novamente.

Sei que escrever um "select *" é tentador, porque realmente não gosto de especificar manualmente todos os campos das minhas consultas, mas quando o sistema começar a evoluir, você verá que vale a pena gastar esse tempo extra/esforço na especificação dos campos, em vez de gastar muito mais tempo e esforço removendo erros em suas visualizações ou otimizando seu aplicativo.

3
Alexandre Brasil

Embora listar explicitamente as colunas seja bom para o desempenho, não fique louco.

Portanto, se você usar todos os dados, tente SELECT * por simplicidade (imagine ter muitas colunas e fazer uma consulta JOIN ... pode ficar horrível). Então - meça. Compare com a consulta com nomes de colunas listados explicitamente.

Não especule sobre desempenho, meça!

A listagem explícita ajuda mais quando você tem alguma coluna que contém grandes dados (como o corpo de uma postagem ou artigo) e não precisa disso em uma consulta específica. Então, ao não devolvê-lo na sua resposta, o servidor de banco de dados pode economizar tempo, largura de banda e taxa de transferência de disco. O resultado da sua consulta também será menor, o que é bom para qualquer cache de consulta.

3
Paweł Hajdan

definindo definitivamente as colunas, porque o SQL Server não precisará fazer uma pesquisa nas colunas para obtê-las. Se você definir as colunas, o SQL poderá ignorar essa etapa.

3
Nick Berardi

É sempre melhor especificar as colunas necessárias, se você pensar uma vez, o SQL não precisará pensar "wtf is *" toda vez que você consultar. Além disso, alguém mais tarde pode adicionar colunas à tabela que você realmente não precisa na sua consulta e, nesse caso, você terá uma melhor situação ao especificar todas as suas colunas.

3
BrewinBombers

A seleção é igualmente eficiente (em termos de velocidade) se você usar * ou colunas.

A diferença é sobre memória, não velocidade. Ao selecionar várias colunas, o SQL Server deve alocar espaço de memória para atender à consulta, incluindo todos os dados de todas as colunas solicitadas, mesmo se você estiver usando apenas uma delas.

O que importa em termos de desempenho é o plano de execução, que por sua vez depende muito da cláusula WHERE e do número de JOIN, OUTER JOIN, etc.

Para sua pergunta, use SELECT *. Se você precisar de todas as colunas, não há diferença de desempenho.

2
Jorge Córdoba

O resultado é muito grande. É lento para gerar e enviar o resultado do mecanismo SQL para o cliente.

O lado do cliente, sendo um ambiente de programação genérico, não é e não deve ser projetado para filtrar e processar os resultados (por exemplo, a cláusula WHERE, a cláusula ORDER), pois o número de linhas pode ser enorme (por exemplo, dezenas de milhões de linhas).

2
kennytm

A nomeação de cada coluna que você espera obter no seu aplicativo também garante que ele não seja interrompido se alguém alterar a tabela, desde que suas colunas ainda estejam presentes (em qualquer ordem).

2
Don

NÃO é mais rápido usar nomes explícitos de campos em relação a *, se e somente se, você precisa obter os dados para todos os campos.

Seu software cliente não deve depender da ordem dos campos retornados, portanto, isso também é um absurdo.

E é possível (embora improvável) que você precise obter todos os campos usando * porque ainda não sabe quais campos existem (pense em uma estrutura de banco de dados muito dinâmica).

Outra desvantagem do uso de nomes de campo explícitos é que, se houver muitos deles e forem longos, isso dificulta a leitura do código e/ou do log de consultas.

Portanto, a regra deve ser: se você precisar de todos os campos, use *, se precisar de apenas um subconjunto, nomeie-os explicitamente.

2
user9385

Depende da versão do seu servidor de banco de dados, mas as versões modernas do SQL podem armazenar em cache o plano de qualquer maneira. Eu diria que vá com o que for mais sustentável com o seu código de acesso a dados.

1
Keith

Um dos motivos é a melhor prática para especificar exatamente quais colunas você deseja devido a possíveis alterações futuras na estrutura da tabela.

Se você estiver lendo dados manualmente usando uma abordagem baseada em índice para preencher uma estrutura de dados com os resultados da sua consulta, no futuro, quando você adicionar/remover uma coluna, terá dores de cabeça tentando descobrir o que deu errado.

Quanto ao que for mais rápido, vou recorrer aos outros por sua experiência.

1
dpollock

E lembre-se, se você tiver uma junção interna por definição, não precisará de todas as colunas, pois os dados nas colunas de junção serão repetidos.

Não é como listar colunas no servidor SQl é difícil ou até demorado. Basta arrastá-los do navegador de objetos (você pode obter tudo de uma só vez, arrastando as colunas do Word). Colocar um impacto permanente no desempenho do sistema (porque isso pode reduzir o uso de índices e o envio de dados desnecessários pela rede é caro) e aumenta a probabilidade de que você tenha problemas inesperados à medida que o banco de dados muda (algumas vezes, são adicionadas colunas que você não deseja que o usuário veja, por exemplo) apenas para poupar menos de um minuto do tempo de desenvolvimento, é míope e pouco profissional.

1
HLGEM

O que todos acima disseram, mais:

Se você está buscando um código legível e sustentável, faça algo como:

SELECIONE foo, bar FROM widgets;

é instantaneamente legível e mostra a intenção. Se você telefonar, sabe o que está recebendo de volta. Se os widgets tiverem apenas colunas foo e barra, selecionar * significa que você ainda precisa pensar no que está recebendo, confirme se o pedido está mapeado corretamente etc. No entanto, se os widgets tiverem mais colunas, mas você estiver interessado apenas em foo e bar, seu código fica confuso quando você solicita um curinga e, em seguida, usa apenas parte do que é retornado.

1
Faisal

SELECT * é necessário se você deseja obter metadados, como o número de colunas.

1
Mark Etable

Para adicionar o que todo mundo disse, se todas as suas colunas que você está selecionando estiverem incluídas em um índice, seu conjunto de resultados será extraído do índice em vez de procurar dados adicionais do SQL.

1
Mike

Como na maioria dos problemas, isso depende do que você deseja alcançar. Se você deseja criar uma grade de banco de dados que permita todas as colunas em qualquer tabela, "Selecionar *" é a resposta. No entanto, se você precisar apenas de determinadas colunas e a adição ou exclusão de colunas da consulta for feita com pouca frequência, especifique-as individualmente.

Também depende da quantidade de dados que você deseja transferir do servidor. Se uma das colunas for definida como memorando, gráfico, blob etc. e você não precisar dessa coluna, é melhor não usar "Selecionar *" ou obterá um monte de dados que não precisa quer e seu desempenho pode sofrer.

1
Mark

A importância ou não da eficiência depende muito do tamanho dos conjuntos de dados de produção (e da taxa de crescimento). Se seus conjuntos de dados não forem tão grandes e não crescerem tão rapidamente, pode não haver uma grande vantagem de desempenho na seleção de colunas individuais.

Com conjuntos de dados maiores e taxas mais rápidas de crescimento de dados, a vantagem de desempenho se torna cada vez mais importante.

Para ver graficamente se existe ou não alguma diferença, sugiro usar o analisador de consultas para ver o plano de execução da consulta para um SELECT * e o equivalente SELECT col1, col2, etc. Isso deve indicar qual das duas consultas é mais eficiente. Você também pode gerar alguns dados de teste de volumes variados para ver quais são os tempos.

0
Scott Lawrence

Vou ser criticado por isso, mas eu faço um select * porque quase todos os meus dados são recuperados das Visualizações do SQL Server que pré-combinam os valores necessários de várias tabelas em um único e fácil acesso.

Quero, então, todas as colunas da exibição que não serão alteradas quando novos campos forem adicionados às tabelas subjacentes. Isso tem o benefício adicional de permitir que eu altere a origem dos dados. O campo A na visualização pode ser calculado ao mesmo tempo e, em seguida, posso alterá-lo para ser estático. De qualquer maneira, o View fornece o FieldA para mim.

A vantagem disso é que ele permite que minha camada de dados obtenha conjuntos de dados. Em seguida, passa-os para o meu BL, que pode criar objetos a partir deles. Meu aplicativo principal apenas conhece e interage com os objetos. Eu até permito que meus objetos se auto-criem quando passam por uma datarow.

Claro, eu sou o único desenvolvedor, então isso ajuda também :)

0
klkitchens

Defina absolutamente as colunas que você deseja SELECIONAR sempre. Não há razão para não fazê-lo e a melhoria do desempenho vale a pena.

Eles nunca deveriam ter dado a opção de "SELECT *"

0
cazlab

Se você precisar de todas as colunas, basta usar SELECT *, mas lembre-se de que a ordem pode mudar, portanto, quando você estiver consumindo os resultados, acesse-os por nome e não por índice.

Eu ignoraria os comentários sobre como * precisa ir para a lista - as chances de analisar e validar colunas nomeadas são iguais ao tempo de processamento, se não mais. Não otimize prematuramente ;-)

0
DamienG

A principal diferença entre os dois é a quantidade de dados transmitidos para frente e para trás. Qualquer argumento sobre a diferença de horário é fundamentalmente defeituoso, pois "select *" e "select col1, ..., colN" resultam na mesma quantidade de trabalho relativo executado pelo mecanismo do DB. No entanto, transmitir 15 colunas por linha vs. 5 colunas por linha é uma diferença de 10 colunas.

0
Jeff Hubbard

Em termos de eficiência de execução, não conheço nenhuma diferença significativa. Mas, para a eficiência dos programadores, eu escreveria os nomes dos campos porque

  • Você conhece a ordem se precisar indexar por número ou se o seu driver se comportar de maneira engraçada nos valores de blob e precisar de uma ordem definida
  • Você só lê os campos necessários, se precisar adicionar mais campos
  • Você obtém um erro sql se digitar incorretamente ou renomear um campo, e não um valor vazio de um conjunto de registros/linha
  • Você pode ler melhor o que está acontecendo.
0
Erik

Vejo que várias pessoas parecem pensar que leva muito mais tempo para especificar as colunas. Como você pode arrastar a lista de colunas do navegador de objetos, talvez leve um minuto extra para especificar colunas (ou seja, se você tiver muitas colunas e precisar gastar algum tempo colocando-as em linhas separadas) na consulta. Por que as pessoas pensam que é tão demorado?

0
HLGEM

Eu sempre recomendo especificar as colunas necessárias, caso seu esquema mude e você não precise da coluna extra.

Além disso, qualifique os nomes das colunas com o nome da tabela. Isso é crítico quando a consulta contém junções. Sem as qualificações da tabela, pode ser difícil lembrar qual coluna vem de qual tabela e adicionar uma coluna com nome semelhante a uma das outras tabelas pode interromper sua consulta.

0
mxsscott

Em termos de desempenho, vi comentários de que ambos são iguais. mas no aspecto da usabilidade existem alguns + e 's

Quando você usa um (selecione *) em uma consulta e se alguém altera a tabela e adiciona novos campos que não precisam da consulta anterior, é uma sobrecarga desnecessária. E se o campo recém-adicionado for um blob ou um campo de imagem ??? o tempo de resposta da sua consulta será muito lento.

Por outro lado, se você usar a (selecione col1, col2, ..) e se a tabela for alterada e adicionar novos campos e se esses campos forem necessários no conjunto de resultados, você sempre precisará editar sua consulta de seleção após a alteração da tabela.

Mas sugiro sempre usar select col1, col2, ... nas suas consultas e alterar a consulta se a tabela for alterada mais tarde ...

0
Lahiru Cooray

É particularmente importante que o desempenho não use select * quando você tem uma associação porque, por definição, pelo menos dois campos contêm os mesmos dados. Você não deseja desperdiçar recursos de rede enviando dados desnecessários do servidor de banco de dados para o aplicativo ou servidor da web. Pode parecer mais fácil usar o select *, mas é uma prática ruim. Como é fácil arrastar os nomes das colunas para a consulta, basta fazer isso.

Outro problema que ocorre ao usar o select * é que existem idiotas que optam por adicionar novos campos no meio da tabela (sempre uma prática ruim), se você usar o select * como base para uma inserção, de repente a ordem da coluna pode ser errado e você pode tentar inserir o número da previdência social no honorário (a quantidade de dinheiro que um orador pode receber para escolher um exemplo não aleatório), o que pode ser muito ruim para a integridade dos dados. Mesmo que a seleção não seja uma inserção, fica ruim para o cliente quando os dados estão subitamente na ordem de desgaste no relatório ou na página da web.

Penso que não há circunstância quando usar select * é preferível a usar uma lista de colunas. Você pode achar que é mais fácil de manter, mas, na verdade, não é e fará com que seu aplicativo fique mais lento sem motivo quando campos que você não precisa são adicionados às tabelas. Você também terá que enfrentar o problema de consertar coisas que não teriam quebrado se você tivesse usado uma lista de colunas; portanto, o tempo que você economiza ao não adicionar uma coluna é usado para isso.

0
HLGEM

ei, seja prático. use select * ao prototipar e selecione colunas específicas ao implementar e implantar. da perspectiva do plano de execução, ambos são relativamente idênticos nos sistemas modernos. no entanto, selecionar colunas específicas limita a quantidade de dados que precisam ser recuperados do disco, armazenados na memória e enviados pela rede.

em última análise, o melhor plano é selecionar colunas específicas.

0
siculars

Lembre-se também das mudanças. Hoje, o Select * seleciona apenas as colunas de que você precisa, mas amanhã também pode selecionar a coluna varbinary (MAX) que eu acabei de adicionar sem informar, e agora você também está recuperando todos os 3,18 Gigabytes de dados binários que não estavam disponíveis ontem na mesa.

0
Michael Stum

Vamos pensar sobre o que é mais rápido. Se você pode selecionar apenas os dados necessários, é mais rápido. No entanto, nos testes, você pode extrair todos os dados para julgar quais dados podem ser filtrados com base nas necessidades da empresa.

0
mikedopp

Há casos em que SELECT * é bom para fins de manutenção, mas, em geral, deve ser evitado.

Esses são casos especiais, como visualizações ou procedimentos armazenados, nos quais você deseja que as alterações nas tabelas subjacentes sejam propagadas sem a necessidade de alterar todas as visualizações e procs armazenados que usam a tabela. Mesmo assim, isso pode causar problemas, como no caso em que você tem duas visualizações unidas. Uma tabela subjacente é alterada e agora a exibição é ambígua, porque ambas as tabelas têm uma coluna com o mesmo nome. (Observe que isso pode acontecer sempre que você não qualificar todas as suas colunas com prefixos de tabela). Mesmo com prefixos, se você tiver uma construção como:

SELECIONE A ., B. - você pode ter problemas nos quais o cliente agora tem dificuldade em selecionar o campo certo.

Em geral, eu não uso SELECT *, a menos que esteja tomando uma decisão consciente do projeto e contando que os riscos relacionados sejam baixos.

0
Cade Roux

O SELECT *pode estará ok se você realmente precisar de todas as colunas - mas ainda deve listá-las todas individualmente. Você certamente não deve selecionar todas as linhas de uma tabela - mesmo se o aplicativo e o banco de dados estiverem no mesmo servidor ou rede. A transferência de todas as linhas levará tempo, especialmente à medida que o número de linhas aumenta. Você deve ter pelo menos uma cláusula where que filtre os resultados e/ou pagine os resultados para selecionar apenas o subconjunto de linhas que precisam ser exibidas. Existem várias ferramentas ORM, dependendo do idioma do aplicativo que você está usando para ajudar na consulta e na paginação do subconjunto de dados que você precisa. Por exemplo, no .NET Linq to SQL, Entity Framework e nHibernate, todos irão ajudá-lo.

0
bkaid

Use nomes de campos específicos; portanto, se alguém alterar a tabela com você, você não obterá resultados inesperados. Sobre o assunto: SEMPRE especifique os nomes dos campos ao fazer uma inserção; portanto, se você precisar adicionar uma coluna posteriormente, não precisará voltar e corrigir o programa e alterar o banco de dados ao mesmo tempo no release de produção.

0
stu

Se você está preocupado com a velocidade, use declarações preparadas. Caso contrário, estou com ilitirit que muda é contra o que você se protege.

/ Allan

0
Allan Wind

Acho que listar nomes de colunas é particularmente importante se é provável que outros desenvolvedores trabalhem com o código ou se é provável que o banco de dados seja alterado, para que você sempre obtenha dados consistentes.

0
Sam Cogan

Esta é uma postagem antiga, mas ainda válida. Para referência, eu tenho uma consulta muito complicada que consiste em:

  • 12 mesas
  • 6 Junções esquerdas
  • 9 junções internas
  • 108 total de colunas em todas as 12 tabelas
  • Eu só preciso de 54 colunas
  • Uma cláusula Order By de 4 colunas

Quando executo a consulta usando o Select *, leva em média 2869ms. Quando executo a consulta usando o Select, leva uma média de 1513ms.

O total de linhas retornadas é 13.949.

Não há dúvida de que selecionar nomes de colunas significa um desempenho mais rápido do que o Select *

0

Para consultar o banco de dados diretamente (como em um prompt do sqlplus ou por meio de uma ferramenta de administração do banco de dados), selecione * geralmente é bom - economiza o trabalho de escrever todas as colunas.

Por outro lado, no código do aplicativo, é melhor enumerar as colunas. Isso tem vários benefícios:

  • O código é mais claro
  • Você saberá a ordem em que os resultados retornarão (isso pode ou não ser importante para você)
0
Morikal

Bem, isso realmente depende de suas métricas e finalidade:

  1. Se você possui 250 colunas e deseja (de fato) selecionar todas, use select * se quiser chegar em casa no mesmo dia :)
  2. Se sua codificação precisar de flexibilidade e a tabela precisar for pequena, novamente, selecione * ajuda a codificar mais rapidamente e a mantê-lo mais fácil.
  3. Se você deseja engenharia e desempenho robustos:
    • escreva os nomes das colunas, se forem apenas alguns, ou
    • escreva uma ferramenta que permita selecionar/gerar facilmente seus nomes de coluna

Como regra geral, quando preciso selecionar todas as colunas, usaria "select *", a menos que tenha um motivo muito específico para fazer o contrário (além disso, acho que é mais rápido em tabelas com muitas, muitas colunas)

E por último, mas não menos importante, como você deseja adicionar ou excluir uma coluna na tabela para afetar seu código ou sua manutenção?

0
Notitze