-
GROUP_CONCAT() का उपयोग आमतौर पर समूह-दर तर्क को आमंत्रित करता है और अस्थायी तालिका बनाता है, जो आमतौर पर प्रदर्शन के लिए एक बड़ा नकारात्मक होता है। कभी-कभी आप समूह-दर-क्वेरी में अस्थायी तालिका से बचने के लिए सही अनुक्रमणिका जोड़ सकते हैं, लेकिन हर मामले में नहीं।
-
जैसा कि @MarcB बताता है, समूह-संबद्ध स्ट्रिंग की डिफ़ॉल्ट लंबाई सीमा बहुत कम है, और बहुत से लोग छोटी सूचियों से भ्रमित हो गए हैं। आप group_concat_max_len ।
-
PHP में एक स्ट्रिंग को एक सरणी में विस्फोट करना मुफ्त में नहीं आता है। सिर्फ इसलिए कि आप इसे PHP में एक फ़ंक्शन कॉल में कर सकते हैं इसका मतलब यह नहीं है कि यह प्रदर्शन के लिए सबसे अच्छा है। मैंने अंतर को बेंचमार्क नहीं किया है, लेकिन मुझे संदेह है कि आपके पास भी है।
-
GROUP_CONCAT() एक MySQLism है। यह अन्य SQL उत्पादों द्वारा व्यापक रूप से समर्थित नहीं है। कुछ मामलों में (जैसे SQLite), उनके पास एक GROUP_CONCAT() फ़ंक्शन होता है, लेकिन यह बिल्कुल MySQL की तरह काम नहीं करता है, इसलिए यदि आपको कई RDBMS बैक-एंड का समर्थन करना है, तो इससे भ्रमित करने वाले बग हो सकते हैं। बेशक, अगर आपको पोर्टिंग के बारे में चिंता करने की ज़रूरत नहीं है, तो यह कोई समस्या नहीं है।
-
अगर आप अपनी
currenciesसे कई कॉलम लाना चाहते हैं तालिका, तो आपको एकाधिक GROUP_CONCAT() अभिव्यक्तियों की आवश्यकता है। क्या सूचियों के उसी क्रम में होने की गारंटी है? अर्थात्, क्या एक सूची में तीसरा क्षेत्र अगली सूची में तीसरे क्षेत्र के अनुरूप है? उत्तर नहीं है -- तब तक नहीं जब तक कि आपORDER BY. के साथ ऑर्डर निर्दिष्ट नहीं करते हैं GROUP_CONCAT () के अंदर क्लॉज।
मैं आमतौर पर आपके पहले कोड प्रारूप का समर्थन करता हूं, एक पारंपरिक परिणाम सेट का उपयोग करता हूं, और परिणामों पर लूप करता हूं, क्लाइंट आईडी द्वारा अनुक्रमित एक नई सरणी में सहेजता हूं, मुद्राओं को एक सरणी में जोड़ता हूं। यह एक सीधा समाधान है, SQL को सरल और अनुकूलित करने में आसान रखता है, और यदि आपके पास लाने के लिए कई कॉलम हैं तो यह बेहतर काम करता है।
मैं यह कहने की कोशिश नहीं कर रहा हूं कि GROUP_CONCAT() खराब है! यह कई मामलों में वास्तव में उपयोगी है। लेकिन किसी भी फ़ंक्शन या भाषा सुविधा का उपयोग करने (या बचने के लिए) के लिए कोई भी एक आकार-फिट-सभी नियम बनाने की कोशिश करना सरल है।
