2010-10-11 14 views
8

मैं एक ऑनलाइन ऐप के लिए कस्टम फ़ील्ड के लिए एक जटिल MySQL डेटा संरचना समस्या का उत्तर देने का प्रयास कर रहा हूं। मैं माइस्क्ल के लिए बिल्कुल नया हूं इसलिए किसी भी इनपुट की सराहना की जाती है।ऐरे, ईएवी, कस्टम फ़ील्ड के लिए सीरियलाइज्ड LOB?

वर्तमान डेटाबेस एक रिलेशनल डेटाबेस है और सेवा के प्रत्येक उपयोगकर्ता एक ही डेटाबेस और टेबल साझा करेंगे।

यहां एक उदाहरण है जो मैं करने की कोशिश कर रहा हूं।

मान लें कि मैं एक सूची बनाने की कोशिश कर रहा हूं। इस सूची में 30 कस्टम फ़ील्ड हो सकते हैं। उपयोगकर्ता 12 अद्वितीय तत्वों के बीच चयन कर सकता है और प्रत्येक तत्व में 15 उपयोगकर्ता परिभाषित गुण हो सकते हैं।

प्रत्येक सूची खाते के साथ-साथ खातों के बीच अद्वितीय हो सकती है। खातों में कई सूचियां हो सकती हैं और प्रत्येक सूची में विभिन्न तत्वों के साथ-साथ प्रति तत्व के विभिन्न गुण हो सकते हैं।

एक तत्व बहुत सी बातें, उदाहरण के लिए हो सकता है: बहुविकल्पीय, रेडियो बटन, फोन क्षेत्र, पता, एकल लाइन पाठ, बहु लाइन पाठ, आदि

एक बहु विकल्प के लिए विशेषताओं का एक उदाहरण (चेक बॉक्स) तत्व हो सकता है: लाल, हरा, नीला, नारंगी, सफेद, काला

एक पंक्ति पाठ तत्व का एक उदाहरण हो सकता है: पहला नाम इनपुट फ़ील्ड।

प्रत्येक तत्व में उपयोगकर्ता परिभाषित शीर्षक फ़ील्ड और टैग फ़ील्ड भी होना चाहिए जिसे ऐप की अन्य सुविधाओं में संदर्भित और उपयोग किया जा सकता है।

सेगमेंटेशन भी बहुत महत्वपूर्ण है। किसी उपयोगकर्ता को किसी भी तत्व के आधार पर सूची को विभाजित करने में सक्षम होना चाहिए। उदाहरण के लिए, उपयोगकर्ता सभी रिकॉर्ड्स पर आधारित "लाल" सूची को "एबीसी" सेगमेंट करना चाहता है, जहां कई विकल्प तत्व # 1 में "लाल" मौजूद होता है (उनके पास सूची के लिए 1 से अधिक विकल्प तत्व हो सकते हैं)।

इस उदाहरण में मुझे लगता है कि सरणी, ईएवी, सीरियलाइज्ड LOB ठीक काम करेगा। हालांकि, मुझे यकीन नहीं है कि मेरे पैमाने पर मेरी आवश्यकताओं के लिए सबसे अच्छी संरचना क्या होगी।

असल में, प्रति सूची 50,000 रिकॉर्ड होने की संभावना अधिक होगी और 20,000+ खातों की वास्तविक संभावना है - प्रत्येक में कई सूचियां हैं। इसलिए, मैं सबसे कुशल और लचीली संरचना की तलाश में हूं।

मामलों को और भी जटिल बनाने के लिए मुझे किसी भी समय किसी भी विशेष सूची में तत्व जोड़ने/हटाने का एक प्रभावी तरीका सुनिश्चित करने की आवश्यकता है। उदाहरण के लिए, यदि कोई उपयोगकर्ता कस्टम फ़ील्ड (30) की अधिकतम अनुमति संख्या के साथ एक सूची बनाता है और फिर तीन महीने बाद फैसला करता है कि वे एक फ़ील्ड को हटाना चाहते हैं, तो मुझे उस सूची और उस कस्टम फ़ील्ड के सभी संबंधित मानों को ढूंढने का एक तरीका चाहिए और फिर सभी मानों, तत्व प्रकार और इसके गुणों को हटा दें। तब उपयोगकर्ता को इस सूची में एक नया तत्व जोड़ने की अनुमति दी जाएगी।

मैंने इस साइट पर कई ईएवी पोस्ट की समीक्षा की है, साथ ही यह http://www.martinfowler.com/eaaCatalog/serializedLOB.html ऐसा प्रतीत नहीं होता है कि डेटा पुनर्प्राप्ति डाउनसाइड्स के कारण ईएवी मेरी आवश्यकताओं के लिए बहुत ही कुशल होगा।

मैं यह भी सोच रहा था कि इस पैमाने पर बहु-आयामी सरणी कितनी अच्छी तरह से काम करेगी? मेरा मानना ​​है कि वर्डप्रेस अपने कस्टम फ़ील्ड के लिए इसका इस्तेमाल करता है।

किसी भी इनपुट की सराहना की जाएगी कि इस स्थिति के लिए डेटाबेस को सर्वोत्तम तरीके से कैसे व्यवस्थित किया जाए। धन्यवाद!

+0

मुझे भी एक ही चुनौती का सामना करना पड़ रहा है - आप किस समाधान के साथ गए थे? मुझे आपके अनुभवों में बहुत दिलचस्पी होगी। – philwilks

उत्तर

0

आप जेसन एन्कॉन्डिंग और डिकोडिंग का उपयोग कर सकते हैं (मुझे लगता है कि आप PHP का उपयोग कर रहे हैं) कॉलम के साथ एक तालिका में इनपुट जानकारी स्टोर करने के लिए उपयोगकर्ता को स्टोर करने के लिए और अन्य को इस डेटा को टेक्स्ट के रूप में स्टोर करने के लिए। उत्तरों को किसी अन्य तालिका में संग्रहीत किया जाना चाहिए (FK के साथ CASCADE को DELETE का उपयोग करने के लिए)।

यदि आप इनपुट विनिर्देश के अधिकतम आकार को निर्दिष्ट कर सकते हैं, तो वर्चर फ़ील्ड का उपयोग करें।

यह सबसे अच्छा अपरिवर्तनीय नहीं हो सकता है (यह सुनिश्चित करने के लिए कुछ प्रोफाइलिंग परीक्षणों की आवश्यकता है कि यह पर्याप्त मजबूत है) लेकिन निश्चित रूप से उपयोग किया जा सकता है।

1

आप के बारे में कैसे FriendFeed कस्टम फ़ील्ड को लागू करता है पढ़ सकते हैं: http://bret.appspot.com/entry/how-friendfeed-uses-mysql

वे उल्टे अनुक्रमित युक्त अतिरिक्त तालिकाओं के साथ धारावाहिक LOB के संयोजन का उपयोग,। आपको अपने LOB में प्रत्येक संभावित विशेषता के लिए अतिरिक्त तालिका की आवश्यकता नहीं है, केवल वही जिन्हें आप किसी इंडेक्स से सहायता के साथ खोजना चाहते हैं।

+0

http://bret.appspot.com/entry/how-friendfeed-uses-mysql नहीं मिला –

+0

@ वांग्यारन, आश्चर्य की बात नहीं है कि ब्लॉग 6 साल से अधिक पुराना है। मैं यहां अपनी प्रस्तुति में उलटा इंडेक्सिंग की एक ही तकनीक का वर्णन करता हूं: http://www.slideshare.net/billkarwin/extensible-data-modeling। –

संबंधित मुद्दे