SQL सर्वर

Question

में संग्रहीत (उत्पाद) विशेषताओं के लिए सर्वोत्तम पैटर्न हम एक नई परियोजना शुरू कर रहे हैं जहां हमें डेटाबेस में उत्पाद और कई उत्पाद विशेषताओं को स्टोर करने की आवश्यकता है। डेटा स्टैक के लिए प्रौद्योगिकी स्टैक एमएस एसक्यूएल 2008 और एंटिटी फ्रेमवर्क 4.0/LINQ है।

उत्पाद (और उत्पाद तालिका) बहुत सरल हैं (एक एसकेयू, निर्माता, मूल्य, आदि ..)। हालांकि प्रत्येक उत्पाद के साथ स्टोर करने के लिए कई विशेषताएं भी हैं (औद्योगिक विजेट सोचें)। ये रंग से प्रमाणन (ओं) तक पाइप आकार तक हो सकते हैं। प्रत्येक उत्पाद में अलग-अलग गुण हो सकते हैं, और कुछ में एक ही गुण (गुण: प्रमाणन) के गुणक हो सकते हैं।

वर्तमान प्रस्ताव यह है कि हम मूल रूप से प्रत्येक पंक्ति में उत्पाद आईडी पर एफके के साथ नाम/मूल्य जोड़ी तालिका रखेंगे।

गुण तालिका का एक उदाहरण कुछ ऐसा दिखाई देगा:

ProdID  AttributeName  AttributeValue 
123  Color    Blue 
123  FittingSize  1.25 
123  Certification  AS1111 
123  Certification  EE2212 
123  Certification  FM.3 
456  Pipe    11 
678  Color    Red 
999  Certification  AE1111 
... 

नोट: गुण नाम होने की संभावना एक लुकअप तालिका या enum से आएगा।

तो यहां मुख्य प्रश्न यह है: क्या ऐसा कुछ करने के लिए यह सबसे अच्छा पैटर्न है? प्रदर्शन कैसे होगा? क्वेरीज उत्पाद और विशेषता तालिका के जॉइन पर आधारित होंगी, और आम तौर पर विशिष्ट विशेषताओं पर फ़िल्टर करने के लिए कई WHEREs की आवश्यकता होती है - सबसे आम खोज ज्ञात/वांछित विशेषताओं के सेट के आधार पर उत्पाद ढूंढना होगा।

अगर किसी के पास इस प्रकार के डेटा के लिए कोई सुझाव या बेहतर पैटर्न है, तो कृपया मुझे बताएं।

धन्यवाद! एड

Answer 1

आप डरावने ईएवी मॉडल, एंटिटी-एट्रिब्यूट-वैल्यू को फिर से आविष्कार करने वाले हैं। वास्तविक कारणों में समस्याएं होने के लिए यह कुख्यात है, कई कारणों से, कई लोग डेव के जवाब से ढके हैं।

Luckly एसक्यूएल ग्राहक सलाहकार दल (SQLCAT) विषय पर एक श्वेतपत्र, Best Practices for Semantic Data Modeling for Performance and Scalability है। मैं अत्यधिक इस पेपर की सिफारिश करता हूं। दुर्भाग्य से, यह एक पैनसिया, एक कुकी कटर समाधान प्रदान नहीं करता है, क्योंकि समस्या का कोई समाधान नहीं है।

सिमेंटिक डेटा मॉडल बहुत जटिल और अर्थ डेटाबेस तक जा सकता है: इसके बजाय, आप कैसे एक निश्चित queryable स्कीमा और एक लचीला EAV संरचना, एक संतुलन है कि आपके विशिष्ट मामले के लिए काम करता है के बीच संतुलन बनाना सीखेंगे आम तौर पर उपलब्ध हैं, चुनौती शुद्ध ऑब्जेक्ट मॉडल और प्रत्येक एप्लिकेशन के लिए शुद्ध संबंध मॉडल के बीच इष्टतम संतुलन ढूंढने के लिए बनी हुई है। सफलता की कुंजी समस्याओं को समझने के लिए है, उन समस्याओं के लिए आवश्यक शमन बनाना, और फिर परीक्षण, परीक्षण और परीक्षण करें। स्केलेबिलिटी परीक्षण एक महत्वपूर्ण सफलता कारक है यदि आप पर जा रहे हैं तो इष्टतम डिज़ाइन ढूंढें।

Answer 2

यह एक कारण के एक जोड़े के लिए समस्याग्रस्त होने जा रहा है:

• आपका इकाई प्रश्नों बहुत कठिन लिखने के लिए किया जाएगा। प्रस्तुति के लिए समय आने पर व्यूमोडेल जैसा कुछ प्रश्नों में उन प्रश्नों के परिणामों को बदलना दर्दनाक होगा क्योंकि इसमें प्रत्येक उत्पाद के लिए एक पिवट शामिल होगा।

• कुछ प्रकार के डेटा पढ़ने के लिए समय आने पर आपके डेटाटाइप क्या होंगे, यह समझना कठिन होगा। क्या आप इसे तारों के रूप में संग्रहीत करने की योजना बना रहे हैं? उदाहरण के लिए, डेटटाइम डिफ़ॉल्ट से अधिक डेटा धारण करते हैं। ToString() कार्यान्वयन स्ट्रिंग को लिखता है। यदि आप फ़्लोटिंग-पॉइंट मानों को स्टोर करने का प्रयास करते हैं तो आपको भी समस्याएं आ रही हैं।

• आपकी ऑब्जेक्ट की डेटा अखंडता जोखिम पर है। गुणों को रखने का एक प्रलोभन होगा जो इस "बाल्टी ओ 'डेटा में आपके मुख्य उत्पाद तालिकाओं के केवल गुण होना चाहिए। हो सकता है कि डिज़ाइन अर्द्ध-सेन शुरू हो जाए, लेकिन मैं आपको गारंटी देता हूं कि कुछ निश्चित समय के बाद, लोग बैग में गुणों को फेंकना शुरू कर देंगे। तब आपकी वस्तुओं की अखंडता को इतनी कम परिभाषित संरचना के साथ रखना बहुत कठिन होगा।

• आपकी अनुक्रमणिका सबसे अधिक संभावना उपरोक्त होगी। फिर एक ऐसी संपत्ति के बारे में सोचें जो आपकी उत्पाद तालिका पर होनी चाहिए। केवल एक कॉलम पर इंडेक्स करने में सक्षम होने के बजाय, अब आपको अपनी "टाइप" टेबल पर संभावित रूप से बहुत बड़ी समग्र इंडेक्स बनाने के लिए मजबूर होना होगा।

• चूंकि आप स्पष्ट रूप से उचित डेटाटाइप फेंकने और तारों का उपयोग करने की योजना बना रहे हैं, तो संख्यात्मक डेटा के लिए रेंज क्वेरी का प्रदर्शन खराब होगा।

• आपकी तालिका बड़ी, धीमी बैकअप और क्वेरी प्राप्त करेगी।एक पूर्णांक 4 बाइट्स के बजाय, आपको किसी भी आकार के पूर्णांक के लिए कहीं अधिक स्टोर करना होगा।

"आईएस-ए" संबंधों का उपयोग करके अधिक "पारंपरिक" तरीके से तालिका को सामान्य करने के लिए बेहतर है। उदाहरण के लिए, आपके पास पाइप्स हो सकते हैं, जो कि एक प्रकार का उत्पाद है, लेकिन इसमें कुछ और विशेषताएं हैं। आपके पास स्टोव हो सकते हैं, जो कि एक प्रकार का उत्पाद है, लेकिन अभी भी कुछ और विशेषताएं हैं।

यदि आपके पास वास्तव में एक सामान्य डेटाबेस और अन्य गुणों के सभी प्रकार हैं जो डेटा अखंडता नियमों के अधीन नहीं होंगे, तो आप बहुत अच्छी तरह से XML कॉलम में डेटा संग्रहीत करने पर विचार करना चाहेंगे। आपको यह बताना मुश्किल है कि सही डिज़ाइन विकल्प क्या है जब तक कि मैं आपके व्यवसाय के बारे में बहुत कुछ नहीं जानता।

आईएमओ यह एक डिज़ाइन एंटीपाटर है। इस विचार के सायरन गीत ने एक डेवलपर को एक अनजान आवेदन के चट्टानों पर आकर्षित किया है।

Answer 3

नाम-मूल्य तालिका रखने की बजाय, सामान्य उत्पाद तालिका संरचना को सभी सामान्य विशेषताओं वाले बनाएं, और उत्पाद द्वारा भिन्न विशेषताओं के लिए एक XML कॉलम जोड़ें।

मैंने पहले इस संरचना का उपयोग किया है और यह काफी अच्छा काम करता है।

@ डेव मार्कले का उल्लेख है, नाम-मूल्य दृष्टिकोण दर्द की दुनिया का कारण बन सकता है।

Answer 4

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

समाधान, आईएमओ, एक संकर है। सामान्य विशेषताओं के लिए, कॉलम/मानक स्कीमा का उपयोग करें। अतिरिक्त, मनमाने ढंग से विशेषताओं के लिए, एक ईएवी का उपयोग करें। हालांकि, ईएवी डेटा के साथ नियम यह है कि आप किसी भी परिस्थिति में कभी भी कभी भी एक प्रश्न लिख सकते हैं जिसमें एक विशेषता पर एक प्रकार या फ़िल्टर शामिल है। यानी, आप Where AttributeName = 'Foo' कभी नहीं लिख सकते हैं।स्कीमा का ईएवी भाग डेटा के एक बैग का प्रतिनिधित्व करता है जो केवल ट्रैकिंग उद्देश्यों के लिए है। असल में, मैंने कई लोगों को ईएवी भाग के लिए एक्सएमएल का उपयोग करके इस समाधान को लागू किया है। जिस क्षण कोई व्यक्ति किसी रिपोर्ट पर किसी विशिष्ट स्थान पर ईएवी मान को खोजना, फ़िल्टर करना, क्रमबद्ध करना या स्थान देना चाहता है, तो विशेषता को उत्पाद तालिका में शीर्ष स्तर कॉलम तक बढ़ाया जाना चाहिए।

इस संकर दृष्टिकोण की कुंजी अनुशासन है। एक फ़िल्टर को जोड़ने, सॉर्ट करने या किसी विशेष स्थान पर किसी विशेष स्थान पर विशेष रूप से जब आप प्रबंधन से दबाव प्राप्त करते हैं तो एक विशेषता को जोड़ने के लिए पर्याप्त सरल लगेगा। आपको इस प्रलोभन का विरोध करना चाहिए। एक बार जब आप अंधेरे रास्ते पर जाते हैं ... यदि आपको नहीं लगता कि आप अपनी विकास टीम में उस स्तर के अनुशासन को बनाए रख सकते हैं, तो मैं ईएवी का उपयोग नहीं करूंगा। जैसा कि मैंने पहले उल्लेख किया है, ईएवी दवाओं की तरह हैं: छोटी मात्रा में और सही परिस्थितियों में उपयोग किए जाने पर वे फायदेमंद हो सकते हैं। बहुत ज्यादा तुम्हें मार डालेगा।

Answer 5

मैं जानता हूँ कि यह एक पुराने एक है - लेकिन वहाँ अन्य पाठकों हो सकती है ...

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

यह दृष्टिकोण पूरी तरह से सामान्यीकृत है और पूरी तरह से स्वचालित हो सकता है। चेकिंग का समर्थन कर सकते हैं यदि विशिष्ट विशेषता सेट हैशिंग विशेषता नाम क्लस्टर द्वारा तालिका के रूप में पहले से ही भौतिक रूप से सेट की गई है, उदाहरण के लिए। crc32 (निचला ('रंग ~ फिटिंगिंग ~ पाइप')) जहां एट्रिब्यूट नामों को वर्णानुक्रम में क्रमबद्ध करने की आवश्यकता है। बेशक इसके लिए डेटा डिक्शनरी में हैश होना आवश्यक है। डेटा डिक्शनरी के आधार पर प्रत्येक ऑब्जेक्ट को खोजा जा सकता है ('यूनियन' का उपयोग करके), खासकर यदि डेटा डिक्शनरी एक टेबल है। तालिका के रूप में डेटा डिक्शनरी रखने से आप अनन्य टैबलेटनाम के आधार पर अपनी प्राथमिक (सरोगेट) कुंजी का उपयोग करने की अनुमति देता है, 'एट्रिब्यूट 1', 'एट्रिब्यूट 2' जैसी टेबलों के साथ समाप्त होने के लिए ... अधिकांश डेटाबेस आजकल कुछ बिलियन टेबल का समर्थन करते हैं - इसलिए हम उस छोर पर भी तरह की बचत है। आपके पास बहुत ही सामान्य विशेषताओं वाले उत्पाद कैटलॉग भी हो सकते हैं, जो विस्तारित विशेषता तालिकाओं का संदर्भ देते हैं।

एक खुली समस्या 1: n डेटा सेट हैं। मुझे डर है कि आपको उन्हें अलग-अलग तालिकाओं में सॉर्ट करने की आवश्यकता है। हालांकि यह आपके डेटा प्रस्तुति और पूछताछ रणनीति पर निर्भर करता है। क्या उन्हें हमेशा उत्पाद से जुड़े कॉमा सेपरेटेड स्ट्रिंग के रूप में प्रस्तुत किया जाना चाहिए या आप उदाहरण देना चाहते हैं। एक निश्चित प्रमाणन के सभी उत्पादों के लिए पूछताछ करने में सक्षम हो?

इससे पहले कि आप इस दृष्टिकोण को जलाएं, कृपया इस पर विचार करें: यह उन मामलों के लिए है जहां आपके पास गुणों की गुणवत्ता बहुत अधिक अस्थिरता है - मात्रा और गुणवत्ता में - केवल। इसके अलावा यह प्रीसेट था, कि समाधान के समय जब आप उस बिंदु पर अधिकांश विशेषताओं को नहीं जानते हैं। इसलिए इस संदर्भ में इस पर चर्चा न करें जहां आप अपने गुणों को पहले से मॉडल कर सकते हैं जिससे आप व्यापार को बेहतर तरीके से संतुलित कर सकें।