Grunde til ikke at bruge GROUP_CONCAT?

• Brug af GROUP_CONCAT() kalder normalt gruppe-efter-logikken og skaber midlertidige tabeller, som normalt er en stor negativ for ydeevnen. Nogle gange kan du tilføje det rigtige indeks for at undgå den midlertidige tabel i en gruppe-for-forespørgsel, men ikke i alle tilfælde.

• Som @MarcB påpeger, er standardlængdegrænsen for en gruppesammenkædet streng ret kort, og mange mennesker er blevet forvirrede af trunkerede lister. Du kan øge grænsen med group_concat_max_len .

• Det er ikke gratis at eksplodere en streng i et array i PHP. Bare fordi du kan gøre det i et funktionskald i PHP, betyder det ikke, at det er det bedste for ydeevnen. Jeg har ikke benchmarket forskellen, men det tvivler jeg på, at du har.

• GROUP_CONCAT() er en MySQLism. Det understøttes ikke bredt af andre SQL-produkter. I nogle tilfælde (f.eks. SQLite) har de en GROUP_CONCAT() funktion, men den virker ikke helt på samme måde som i MySQL, så dette kan føre til forvirrende fejl, hvis du skal understøtte flere RDBMS back-ends. Selvfølgelig, hvis du ikke behøver at bekymre dig om portering, er dette ikke et problem.

• Hvis du vil hente flere kolonner fra dine currencies tabel, så har du brug for flere GROUP_CONCAT() udtryk. Er listerne garanteret i samme rækkefølge? Det vil sige, svarer det tredje felt i en liste til det tredje felt i den næste liste? Svaret er nej -- ikke medmindre du angiver ordren med en ORDER BY klausul inde i GROUP_CONCAT().

Jeg foretrækker normalt dit første kodeformat, bruger et konventionelt resultatsæt og går over resultaterne, gemmer til et nyt array indekseret af klient-id og tilføjer valutaerne til et array. Dette er en ligetil løsning, holder SQL enkel og nemmere at optimere og fungerer bedre, hvis du har flere kolonner at hente.

Jeg prøver ikke at sige, at GROUP_CONCAT() er dårligt! Det er virkelig nyttigt i mange tilfælde. Men at prøve at lave en ensartet regel for at bruge (eller undgå) enhver funktion eller sprogfunktion er forenklet.