मान लीजिए कि शॉप प्रोडक्ट की इकाई है, इसमें आम विशेषताएं हैं, जैसे नाम, विवरण, छवि, मूल्य, आदि, जो कई स्थानों पर तर्क में भाग लेते हैं और इसमें (अर्ध) अद्वितीय विशेषताएं हैं, जैसे घड़ी और समुद्र तट की गेंद को पूरी तरह से अलग-अलग पहलुओं द्वारा वर्णित किया जाएगा। । इसलिए मुझे लगता है कि EAV उन (अर्ध) अद्वितीय विशेषताओं को संग्रहीत करने के लिए फिट होगा?
के लिए EAV संरचना का उपयोग करने के कई निहितार्थ हैं जो व्यापार बंद हैं।
आप पंक्ति के लिए 'कम स्थान पर व्यापार कर रहे हैं क्योंकि आपके पास 100 कॉलम नहीं हैं जो null' अधिक जटिल प्रश्नों और मॉडल के खिलाफ हैं ।
ईएवी होने का आमतौर पर मतलब है कि मूल्य एक स्ट्रिंग है जो किसी भी डेटा को भर सकता है। इसके बाद वैधता और बाधा जाँच पर प्रभाव पड़ता है। उस स्थिति पर विचार करें जहां आपने ईएवी तालिका में कुछ के रूप में उपयोग की गई बैटरी की संख्या डाल दी है। आप एक टॉर्च खोजना चाहते हैं जो C आकार की बैटरी का उपयोग करता है, लेकिन उनमें से 4 से कम है।
select P.sku
from
products P
attrib Ab on (P.sku = Ab.sku and Ab.key = "batteries")
attrib Ac on (P.sku = Ac.sku and Ac.key = "count")
where
cast(Ac.value as int) < 4
and Ab.value = 'C'
...
यहाँ महसूस करने वाली बात यह है कि आप मूल्य पर किसी सूचकांक का यथोचित उपयोग नहीं कर सकते हैं। आप किसी को उस चीज़ में डालने से भी नहीं रोक सकते हैं जो वहां पूर्णांक नहीं है, या एक अमान्य पूर्णांक ('-1' बैटरी का उपयोग करता है) क्योंकि मूल्य स्तंभ का उपयोग विभिन्न प्रयोजनों के लिए बार-बार किया जाता है।
इसके बाद उत्पाद के लिए एक मॉडल लिखने की कोशिश में निहितार्थ हैं। आपके पास अच्छे टाइप किए हुए मूल्य होंगे ... लेकिन आप Map<String,String>इसमें हर तरह का सामान रखने के साथ बस बैठे रहने वाले हैं । इसके बाद इसके और भी निहितार्थ हैं जब इसे XML या Json में सीरियल किया जाता है और उन संरचनाओं के खिलाफ सत्यापन या क्वेरी करने की कोशिश की जटिलताएं होती हैं।
विचार करने के लिए पैटर्न के कुछ विकल्प या संशोधन एक मुफ्त फॉर्म कुंजी के बजाय मान्य कुंजी के साथ एक और तालिका है। इसका मतलब है कि डेटाबेस में स्ट्रिंग तुलना करने के बजाय, आप विदेशी कुंजी आईडी की समानता के खिलाफ जांच कर रहे हैं। कुंजी को स्वयं बदलना एक स्थान पर किया जाता है। आपको चाबियों का एक ज्ञात सेट मिला है जिसका अर्थ है कि उन्हें एक एनम के रूप में किया जा सकता है।
आपके पास संबंधित टेबल भी हो सकते हैं जिनमें उत्पाद के एक विशिष्ट वर्ग के गुण होते हैं। एक किराने की विभाग की एक और तालिका हो सकती है जिसमें इसके साथ कई विशेषताएँ जुड़ी होती हैं जिनके लिए भवन निर्माण सामग्री की आवश्यकता नहीं होती है (और इसके विपरीत)।
+----------+ +--------+ +---------+
|Grocery | |Product | |BuildMat |
|id (fk) +--->|id (pk) |<---+id (fk) |
|expiration| |desc | |material |
|... | |img | |... |
+----------+ |price | +---------+
|... |
+--------+
ऐसे समय होते हैं जो विशेष रूप से ईएवी तालिका के लिए कहते हैं।
उस स्थिति पर विचार करें जहां आप अपनी कंपनी के लिए इन्वेंट्री सिस्टम नहीं लिख रहे हैं, जहां आप हर उत्पाद और हर विशेषता को जानते हैं। अब आप अन्य कंपनियों को बेचने के लिए एक इन्वेंट्री सिस्टम लिख रहे हैं। आप हर उत्पाद की हर विशेषता को नहीं जान सकते - उन्हें परिभाषित करने की आवश्यकता होगी।
एक विचार यह है कि बाहर आता है "अगर हम ग्राहक तालिका संशोधित दूँगा" और यह सिर्फ बुरा (आप, टेबल संरचनाओं के लिए मेटा प्रोग्रामिंग में मिल क्योंकि तुम अब पता है कि वह जगह है जहाँ वे कर सकते हैं है शाही संरचना या दूषित गंदगी आवेदन, उन्हें गलत काम करने की पहुँच मिल गई है और उस पहुँच के निहितार्थ महत्वपूर्ण हो गए हैं)। MVC4 में इस पथ के बारे में अधिक जानकारी है : रन समय पर मॉडल कैसे बनाएं?
इसके बजाय, आप व्यवस्थापकीय इंटरफ़ेस को EAV तालिका में बनाते हैं और इसका उपयोग करने की अनुमति देते हैं। यदि ग्राहक 'पोलकडॉट्स' के लिए एक प्रविष्टि बनाना चाहता है, तो यह ईएवी तालिका में जाता है और आप पहले से ही जानते हैं कि इससे कैसे निपटना है।
इसका एक उदाहरण Redmine के लिए डेटाबेस मॉडल में देखा जा सकता है आप custom_fields टेबल देख सकते हैं, और custom_values टेबल - वे EAV के कुछ भाग हैं जो सिस्टम को विस्तारित करने की अनुमति देते हैं।
ध्यान दें कि यदि आप संबंध बनाने के बजाय ईएवी की तरह दिखने के लिए अपनी पूरी तालिका संरचना पाते हैं, तो आप NoSQL (कैसेंड्रा, रेडिस, मोंगो, ...) के केवी स्वाद को देखना चाह सकते हैं । यह महसूस करें कि ये अक्सर उनके डिजाइन में अन्य ट्रेडऑफ के साथ आते हैं जो आपके लिए इसका उपयोग कर रहे हैं या नहीं भी हो सकता है। हालांकि, वे विशेष रूप से एक ईएवी संरचना के इरादे से तैयार किए गए हैं ।
आप इन्वेंट्री प्रबंधन प्रणाली के लिए SQL बनाम NoSQL पढ़ना चाह सकते हैं
डॉक्यूमेंट ओरिएंटेड NoSQL डेटाबेस (काउच, मोंगो) के साथ इस दृष्टिकोण के बाद, आप प्रत्येक इन्वेंट्री आइटम को डिस्क पर एक डॉक्यूमेंट मान सकते हैं ... एक डॉक्यूमेंट में सब कुछ खींचना तेज़ है। इसके अलावा, दस्तावेज़ को संरचित किया जाता है ताकि आप किसी एक एकल चीज़ को तेजी से खींच सकें। दूसरी ओर, किसी विशेष विशेषता से मेल खाने वाली चीज़ों के लिए सभी दस्तावेज़ों को खोजने से कम प्रदर्शन हो सकता है (सभी फ़ाइलों के खिलाफ 'grep' का उपयोग करके) ... इसका सभी व्यापार बंद है।
एक अन्य दृष्टिकोण एलडीएपी होगा जहां एक व्यक्ति के पास अपने सभी संबद्ध वस्तुओं के साथ एक आधार होगा, लेकिन उसके बाद अन्य प्रकार की वस्तुओं के लिए लागू अतिरिक्त ऑब्जेक्ट कक्षाएं भी होंगी। ( LDAP का उपयोग कर सिस्टम इन्वेंटरी देखें )
एक बार जब आप इस रास्ते पर चले जाते हैं, तो आपको कुछ ऐसा मिल सकता है जो वास्तव में आप जिस चीज की तलाश कर रहे हैं ... वह सब कुछ ट्रेडऑफ के साथ आता है।