Eu tenho trabalhado para diferentes empresas e notei que algumas delas preferem ter visões que se juntarão a uma mesa com todos os seus "parentes". Mas no aplicativo algumas vezes, precisamos usar apenas 1 coluna.

Então, seria mais rápido fazer seleções simples e depois "juntá-las" ao código do sistema?

O sistema pode ser php, java, asp, qualquer idioma que se conecte ao banco de dados.

Portanto, a questão é: o que é mais rápido passar do lado do servidor (php, java, asp, ruby, python ...) para o banco de dados, execute uma consulta que obtenha tudo o que precisamos ou do lado do servidor para o banco de dados e execute um consulta que obtém apenas as colunas de uma tabela por vez?

O que abordaria sua pergunta é o assunto JOIN DECOMPOSITION.

De acordo com a página 209 do livro

Você pode decompor uma associação executando várias consultas de tabela única em vez de uma associação multititulada e executando a associação no aplicativo. Por exemplo, em vez desta consulta única:

SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id = tag.id
JOIN post ON tag_post.post_id = post.id
WHERE tag.tag = 'mysql';

Você pode executar estas consultas:

SELECT * FROM tag WHERE tag = 'mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

Por que diabos você faria isso? Parece um desperdício à primeira vista, porque você aumentou o número de consultas sem receber nada em troca. No entanto, essa reestruturação pode realmente oferecer vantagens significativas de desempenho:

• O armazenamento em cache pode ser mais eficiente. Muitos aplicativos armazenam em cache "objetos" que são mapeados diretamente para as tabelas. Neste exemplo, se o objeto com a tag mysqljá estiver armazenado em cache, o aplicativo ignorará a primeira consulta. Se você encontrar postagens com um ID 123, 567 ou 908 no cache, poderá removê-las da IN()lista. O cache de consulta também pode se beneficiar dessa estratégia. Se apenas uma das tabelas mudar com frequência, a decomposição de uma junção poderá reduzir o número de invalidações de cache.
• Às vezes, executar as consultas individualmente pode reduzir a contenção de bloqueio
• A realização de junções no aplicativo facilita o dimensionamento do banco de dados, colocando tabelas em diferentes servidores.
• As consultas em si podem ser mais eficientes. Neste exemplo, o uso de uma IN()lista em vez de uma junção permite que o MySQL classifique os IDs das linhas e recupere as linhas da maneira mais otimizada possível com uma junção.
• Você pode reduzir acessos de linhas redundantes. Fazer uma junção no aplicativo significa recuperar cada linha apenas uma vez., Enquanto uma junção na consulta é essencialmente uma desnormalização que pode acessar repetidamente os mesmos dados. Pelo mesmo motivo, essa reestruturação também pode reduzir o tráfego total da rede e o uso de memória.
• Até certo ponto, você pode ver esta técnica como implementando manualmente uma junção de hash em vez do algoritmo de loops aninhados que o MySQL usa para executar uma junção. Uma junção de hash pode ser mais eficiente.

Como resultado, associações de ações no aplicativo podem ser mais eficientes quando você armazena em cache e reutiliza muitos dados de consultas anteriores, distribui dados em vários servidores, substitui associações por IN()listas ou uma associação se refere à mesma tabela várias vezes.

OBSERVAÇÃO

Gosto do primeiro marcador porque o InnoDB é um pouco pesado quando verifica o cache da consulta.

• Sep 05, 2012: Vale a sobrecarga da invalidação frequente do cache de consulta?
• Jun 07, 2014: Por que query_cache_type está desativado por padrão, a partir do MySQL 5.6?

Quanto ao último marcador, escrevi uma postagem em 11 de março de 2013 ( existe uma diferença de execução entre uma condição JOIN e uma condição WHERE? ) Que descreve o algoritmo de loop aninhado. Depois de ler, você verá o quão boa pode ser a decomposição da junção.

Quanto a todos os outros pontos do livro , os desenvolvedores realmente buscam o desempenho como resultado final. Alguns contam com meios externos (fora do aplicativo) para aprimoramentos de desempenho, como usar um disco rápido, obter mais CPUs / Núcleos, ajustar o mecanismo de armazenamento e ajustar o arquivo de configuração. Outros se prenderão e escreverão um código melhor. Alguns podem recorrer à codificação de toda a inteligência de negócios em Procedimentos armazenados, mas ainda não aplicar a decomposição de junção (consulte Quais são os argumentos contra ou para colocar a lógica do aplicativo na camada do banco de dados? Junto com as outras postagens). Tudo depende da cultura e tolerância de cada loja de desenvolvedores.

Alguns podem ficar satisfeitos com o desempenho e não tocar mais no código. Outros simplesmente não percebem que há grandes benefícios que se pode colher se tentarem ingressar na composição.

Para os desenvolvedores que estão dispostos ...

DE UMA CHANCE !!!

No Postgres (e provavelmente qualquer RDBMS em uma extensão semelhante, MySQL em menor extensão), menos consultas são quase sempre muito mais rápidas.

A sobrecarga de analisar e planejar várias consultas já é mais do que qualquer ganho possível na maioria dos casos.

Para não falar de trabalho adicional a ser feito no cliente, combinando os resultados, o que normalmente é muito mais lento. Um RDBMS é especializado nesse tipo de tarefa e operações são baseadas em tipos de dados originais. Sem conversão para textresultados intermediários ou transformação para tipos nativos do cliente, o que pode levar a resultados menos corretos (ou incorretos!). Pense em números de ponto flutuante ...

Você também transfere mais dados entre o servidor DB e o cliente. Isso pode ser insignificante para uma mão cheia de valores ou fazer uma enorme diferença.

Se várias consultas significam várias viagens de ida e volta para o servidor de banco de dados, você também coleta várias vezes a latência da rede e a sobrecarga da transação, possivelmente até a sobrecarga da conexão. Grande, grande perda.

Dependendo da sua configuração, a latência da rede sozinha pode levar mais tempo do que o resto em ordens de magnitude.

Pergunta relacionada sobre SO:

• Qual é melhor? Executando cálculos em sql ou em seu aplicativo

Pode haver um ponto de virada para consultas muito grandes e de longa execução, porque as transações coletam bloqueios nas linhas do banco de dados no caminho. Consultas muito grandes podem conter muitos bloqueios por um longo período de tempo, o que pode causar atrito com consultas simultâneas .