Anledningar till att inte använda GROUP_CONCAT?

• Användning av GROUP_CONCAT() anropar vanligtvis logiken för gruppering och skapar temporära tabeller, som vanligtvis är ett stort negativt resultat för prestanda. Ibland kan du lägga till rätt index för att undvika temptabellen i en grupp-för-fråga, men inte i alla fall.

• Som @MarcB påpekar är standardlängdgränsen för en gruppsammanfogad sträng ganska kort, och många människor har blivit förvirrade av trunkerade listor. Du kan öka gränsen med group_concat_max_len .

• Att explodera en sträng i en array i PHP är inte gratis. Bara för att du kan göra det i ett funktionsanrop i PHP betyder det inte att det är det bästa för prestanda. Jag har inte jämfört skillnaden, men jag tvivlar på att du har det heller.

• GROUP_CONCAT() är en MySQLism. Det stöds inte brett av andra SQL-produkter. I vissa fall (t.ex. SQLite) har de en GROUP_CONCAT() funktion, men den fungerar inte exakt på samma sätt som i MySQL, så detta kan leda till förvirrande buggar om du måste stödja flera RDBMS back-ends. Naturligtvis, om du inte behöver oroa dig för portering är detta inte ett problem.

• Om du vill hämta flera kolumner från dina currencies tabell, då behöver du flera GROUP_CONCAT()-uttryck. Är listorna garanterat i samma ordning? Det vill säga, motsvarar det tredje fältet i en lista det tredje fältet i nästa lista? Svaret är nej -- inte om du inte anger beställningen med en ORDER BY sats i GROUP_CONCAT().

Jag brukar föredra ditt första kodformat, använda en konventionell resultatuppsättning och gå över resultaten, spara till en ny array indexerad av klient-id, lägga till valutorna till en array. Detta är en okomplicerad lösning, håller SQL enkel och lättare att optimera och fungerar bättre om du har flera kolumner att hämta.

Jag försöker inte säga att GROUP_CONCAT() är dåligt! Det är verkligen användbart i många fall. Men att försöka göra en enhetlig regel för att använda (eller undvika) någon funktion eller språkfunktion är förenklat.