@Jeremy Smith से FIND_IN_SET() उदाहरण पर निर्माण, आप इसे एक जॉइन के साथ कर सकते हैं ताकि आपको एक सबक्वायरी चलाने की आवश्यकता न हो।
SELECT * FROM table t
JOIN locations l ON FIND_IN_SET(t.e_ID, l.city) > 0
WHERE l.e_ID = ?
यह बहुत खराब प्रदर्शन करने के लिए जाना जाता है, क्योंकि इसे प्रत्येक के लिए FIND_IN_SET() फ़ंक्शन का मूल्यांकन करते हुए, टेबल-स्कैन करना पड़ता है। table में पंक्तियों का संयोजन और locations . यह किसी अनुक्रमणिका का उपयोग नहीं कर सकता, और इसे सुधारने का कोई तरीका नहीं है।
मुझे पता है कि आपने कहा था कि आप एक खराब डेटाबेस डिज़ाइन को सर्वश्रेष्ठ बनाने की कोशिश कर रहे हैं, लेकिन आपको यह समझना चाहिए कि यह कितना बुरा है।
व्याख्या:मान लीजिए मैं आपसे एक टेलीफोन बुक में उन सभी लोगों को देखने के लिए कह रहा हूं, जिनका पहला, मध्य या अंतिम अक्षर "J" है। इस मामले में पुस्तक का क्रमबद्ध क्रम किसी भी तरह से मदद नहीं करता है, क्योंकि आपको वैसे भी हर एक पृष्ठ को स्कैन करना होगा।
LIKE @Fthiella द्वारा दिए गए समाधान में प्रदर्शन के संबंध में एक समान समस्या है। इसे अनुक्रमित नहीं किया जा सकता है।
क्या डेटाबेस कॉलम में सीमांकित सूची को स्टोर करना वाकई इतना बुरा है? असामान्य डेटा संग्रहीत करने के इस तरीके के अन्य नुकसानों के लिए।
यदि आप किसी अनुक्रमणिका को संग्रहीत करने के लिए एक पूरक तालिका बना सकते हैं, तो आप शहरों की सूची में प्रत्येक प्रविष्टि के लिए स्थानों को मैप कर सकते हैं:
CREATE TABLE location2city (
location INT,
city INT,
PRIMARY KEY (location, city)
);
मान लें कि आपके पास सभी संभावित शहरों के लिए एक लुकअप टेबल है (न कि केवल table . में उल्लिखित शहरों के लिए ) आप मैपिंग बनाने में एक बार अक्षमता को सहन कर सकते हैं:
INSERT INTO location2city (location, city)
SELECT l.e_ID, c.e_ID FROM cities c JOIN locations l
ON FIND_IN_SET(c.e_ID, l.city) > 0;
अब आप अपनी table . में प्रविष्टियां खोजने के लिए अधिक कुशल क्वेरी चला सकते हैं :
SELECT * FROM location2city l
JOIN table t ON t.e_ID = l.city
WHERE l.e_ID = ?;
यह एक सूचकांक का उपयोग कर सकता है। अब आपको केवल यह ध्यान रखने की आवश्यकता है कि locations में पंक्तियों का कोई भी INSERT/UPDATE/DELETE location2city . में संबंधित मैपिंग पंक्तियों को भी सम्मिलित करता है ।
