मैं उपयोगकर्ता परिभाषित फ़ील्ड और मानों (असीमित संख्या की अनुमति देने) की अनुमति देने के लिए डेटाबेस समाधान की तलाश कर रहा हूं। पहली नज़र में, ईएवी सही फिट की तरह लग रहा था, लेकिन कुछ पढ़ने के बाद मुझे अब यकीन नहीं है।डाटाबेस ईएवी पेशेवर/विपक्ष और विकल्प
ईएवी के पेशेवर और विपक्ष क्या हैं?
क्या उपयोगकर्ता परिभाषित विशेषताओं/फ़ील्ड और मानों को अनुमति देने के लिए कोई वैकल्पिक डेटाबेस विधि है?
इसे एक संपूर्ण उत्तर नहीं माना जाना चाहिए, लेकिन इस विषय पर केवल कुछ बिंदु हैं।
के बाद से सवाल भी [sql] टैग के साथ टैग है, मुझे कहना है कि सामान्य रूप में, relational databasesEAV मॉडल का उपयोग कर डेटा भंडारण के लिये विशेष रूप से उपयुक्त नहीं हैं। आप अभी भी एसक्यूएल में एक ईएवी मॉडल डिज़ाइन कर सकते हैं, लेकिन आपको एक रिलेशनल डेटाबेस देने वाले कई फायदे बलिदान करना होगा। न केवल आप रेफरेंसियल अखंडता को लागू करने, मूल्यों के लिए एसक्यूएल डेटा प्रकारों का उपयोग करने और अनिवार्य विशेषताओं को लागू करने में सक्षम नहीं होंगे, बल्कि यहां तक कि बहुत ही बुनियादी प्रश्न लिखना मुश्किल हो सकता है। वास्तव में, इस सीमा को दूर करने के लिए, कई ईएवी समाधान संबंधित तालिकाओं के साथ जुड़ने के बजाय, डेटा डुप्लिकेशंस पर भरोसा करते हैं, जैसा कि आप कल्पना कर सकते हैं, में बहुत सारी कमीएं हैं।
यदि आपको वास्तव में एक स्कीमालेस डिज़ाइन की आवश्यकता होती है, "असीमित संख्या में गुणों की अनुमति", तो आपकी सबसे अच्छी शर्त शायद NoSQL समाधान का उपयोग करने के लिए है। भले ही संबंधपरक डेटाबेस से संबंधित ईएवी की कमजोरियां भी नोएसक्यूएल विकल्पों पर लागू हों, आपको पारंपरिक एसक्यूएल डेटाबेस के साथ हासिल करने में अतिरिक्त सुविधाएं प्रदान की जाएंगी। उदाहरण के लिए, आमतौर पर नोएसक्यूएल डेटास्टोर को रिलेशनल डेटाबेस से कहीं अधिक आसान बनाया जा सकता है, क्योंकि उन्हें कुछ प्रकार की स्केलेबिलिटी समस्या हल करने के लिए डिज़ाइन किया गया था, और उन्होंने जानबूझकर उन सुविधाओं को छोड़ दिया जो स्केलिंग को मुश्किल बनाते हैं।
कई क्लाउड कंप्यूटिंग प्लेटफार्मों (जैसे Amazon, Google और Microsoft की पेशकश वाली) EAV मॉडल है, जहां विशेषताओं में से एक मनमाना संख्या एक दिया संस्था के साथ जुड़ा हो सकता है के आधार पर डेटा संग्रहों की विशेषता रहे हैं। यदि आप क्लाउड पर अपना आवेदन तैनात करने पर विचार कर रहे हैं, तो आप इसे व्यापार लाभ के साथ-साथ एक तकनीकी दोनों के रूप में भी देख सकते हैं, क्योंकि बड़े विक्रेताओं के बीच मजबूत प्रतिस्पर्धा मूल्य-से-लागत अनुपात को बहुत उच्च स्तर पर धक्का दे रही है, लगातार सुविधाओं पर जोर देकर और वित्तीय और कार्यान्वयन लागत को दबाकर।
मैं नहीं देखता कि ईएवी एक तकनीकी लाभ कैसे है: इसे बनाने, क्वेरी करने और सम्मिलित करने के लिए और अधिक जटिल, और पठनीयता बहुत कम है। एक सरल और तेज़ "चयन * से" धीमा राक्षस एसक्यूएल क्वेरी बन जाएगा। और मैं ईएवी मॉडल के आधार पर कुछ रिपोर्टिंग करने की कोशिश करने के बारे में भी बात नहीं कर रहा हूं। – guigui42
@ guigui42: आपकी टिप्पणी के लिए धन्यवाद। आपके पास एक बिंदु है, लेकिन मेरा जवाब पूर्ण होने का इरादा नहीं था। फिर भी, चूंकि इसे ओपी द्वारा स्वीकार किए जाने के रूप में चिह्नित किया गया था, इसलिए मैंने कुछ और विचारों के साथ उत्तर अपडेट किया है। –
मैं 'रेफरेंसियल अखंडता को लागू करने' भाग पर थोड़ा उलझन में हूं। मैं ईएवी का उपयोग कर रहा हूं और कई विदेशी कुंजी हैं। यूनियन ऑल और कुछ मेटा-डेटा के लिए एकाधिक SQL डेटा प्रकारों का उपयोग किया जा सकता है, जो तालिका (डेटा प्रकार) में विशेषताएँ हैं, जिन्हें वे संग्रहीत करते हैं। आप इकाई तालिका में अतिरिक्त अनुक्रमित कॉलम जोड़कर क्वेरी गति में काफी सुधार कर सकते हैं (जैसे 'प्रकार उदाहरण के लिए)। –
क्या उपयोगकर्ता परिभाषित विशेषताओं/फ़ील्ड और मानों को अनुमति देने के लिए कोई वैकल्पिक डेटाबेस विधि है?
उपयोगकर्ता विकल्प पर आधारित डेटाबेस स्कीमा को बदलने का एक विकल्प है: उदाहरण के लिए जब उपयोगकर्ता एक नया फ़ील्ड चाहता है, तो डेटाबेस में एक संबंधित कॉलम जोड़ें।
इसका नकारात्मक पक्ष यह है कि आपके पास बहुत से खाली फ़ील्ड होंगे –
@ChrisW: जहां परिदृश्य संभव है मेरी राय में बहुत सीमित हैं। –
कुछ डेटाबेस में 'स्पैस' कॉलम (उदा। SQL सर्वर) के लिए समर्थन है जो इस दृष्टिकोण को थोड़ा और अधिक काम करने योग्य बनाता है। – codeulike
posgtres पर एक नज़र hstore http://www.postgresql.org/docs/9.0/static/hstore.html इस वास्तव में आप क्या चाहते हैं नुकसान का सबसे बिना करना होगा है
देखें http://stackoverflow.com/search?q=%5bdatabase%5d%20%2beav&tab=newest –