Причини да не използвате GROUP_CONCAT?

• Използването на GROUP_CONCAT() обикновено извиква логиката group-by и създава временни таблици, които обикновено са голям минус за производителността. Понякога можете да добавите правилния индекс, за да избегнете временната таблица в заявка група по, но не във всеки случай.

• Както @MarcB посочва, ограничението за дължина по подразбиране на групово обединен низ е доста кратко и много хора са били объркани от съкратени списъци. Можете да увеличите лимита с group_concat_max_len .

• Разрастването на низ в масив в PHP не е безплатно. Само защото можете да го направите с едно извикване на функция в PHP, не означава, че е най-доброто за производителност. Не съм сравнявал разликата, но се съмнявам, че и вие сте.

• GROUP_CONCAT() е MySQLism. Не се поддържа широко от други SQL продукти. В някои случаи (например SQLite) те имат функция GROUP_CONCAT(), но тя не работи точно както в MySQL, така че това може да доведе до объркващи грешки, ако трябва да поддържате множество RDBMS back-end. Разбира се, ако не е нужно да се притеснявате за пренасянето, това не е проблем.

• Ако искате да извлечете няколко колони от вашите currencies таблица, тогава имате нужда от множество изрази GROUP_CONCAT(). Гарантирано ли е, че списъците са в същия ред? Тоест третото поле в един списък отговаря ли на третото поле в следващия списък? Отговорът е не – не, освен ако не посочите поръчката с ORDER BY клауза вътре в GROUP_CONCAT().

Обикновено предпочитам първия ви кодов формат, използвам конвенционален набор от резултати и преглеждам резултатите, като записвам в нов масив, индексиран от идентификатора на клиента, добавяйки валутите към масив. Това е просто решение, поддържа SQL прост и лесен за оптимизиране и работи по-добре, ако имате няколко колони за извличане.

Не се опитвам да кажа, че GROUP_CONCAT() е лошо! Това е наистина полезно в много случаи. Но опитът да се създаде универсално правило за използване (или избягване) на която и да е функция или езикова функция е опростено.