-
O uso de GROUP_CONCAT() geralmente invoca a lógica group-by e cria tabelas temporárias, que geralmente são um grande ponto negativo para o desempenho. Às vezes, você pode adicionar o índice correto para evitar a tabela temporária em uma consulta group-by, mas não em todos os casos.
-
Como @MarcB aponta, o limite de comprimento padrão de uma string concatenada em grupo é bem curto e muitas pessoas ficaram confusas com listas truncadas. Você pode aumentar o limite com group_concat_max_len .
-
Explodir uma string em um array em PHP não vem de graça. Só porque você pode fazer isso em uma chamada de função em PHP não significa que é o melhor para o desempenho. Eu não avaliei a diferença, mas duvido que você também tenha.
-
GROUP_CONCAT() é um MySQLismo. Não é amplamente suportado por outros produtos SQL. Em alguns casos (por exemplo, SQLite), eles têm uma função GROUP_CONCAT(), mas não funciona exatamente da mesma forma que no MySQL, então isso pode levar a erros confusos se você tiver que suportar vários back-ends RDBMS. Claro, se você não precisa se preocupar com a portabilidade, isso não é um problema.
-
Se você deseja buscar várias colunas de suascurrenciestable, então você precisa de várias expressões GROUP_CONCAT(). As listas estão garantidas na mesma ordem? Ou seja, o terceiro campo em uma lista corresponde ao terceiro campo na próxima lista? A resposta é não -- a menos que você especifique o pedido com umORDER BYcláusula dentro do GROUP_CONCAT().
Eu costumo favorecer seu primeiro formato de código, usar um conjunto de resultados convencional e fazer um loop sobre os resultados, salvando em um novo array indexado pelo ID do cliente, anexando as moedas a um array. Esta é uma solução direta, mantém o SQL simples e fácil de otimizar e funciona melhor se você tiver várias colunas para buscar.
Não estou tentando dizer que GROUP_CONCAT() é ruim! É realmente útil em muitos casos. Mas tentar fazer qualquer regra de tamanho único para usar (ou evitar) qualquer função ou recurso de linguagem é simplista.
