कॉलम उन्मुख डेटाबेस बनाम पंक्ति उन्मुख डेटाबेस

Question

मैंने लंबे समय तक पंक्ति उन्मुख डेटाबेस डिज़ाइन का उपयोग किया है और डेटावेयर हाउस परियोजनाओं और बिग डेटा नमूने को छोड़कर, मैंने OLTP ऐप के लिए कॉलम उन्मुख डेटाबेस डिज़ाइन का उपयोग नहीं किया है।

मेरे पंक्ति उन्मुख तालिका

तरह

ID, Make, Model, Month, Miles, Cost 
1 BMW Z3  12  12000 100 

हमारी टीम में कुछ लोगों को स्तंभ उन्मुख डेटाबेस डिजाइन की वकालत लग रहा है। वे सुझाव देते हैं कि सभी कॉलम नाम संपत्ति तालिका में संपत्ति के नाम होना चाहिए। फिर एक और तालिका उद्धरण में दो कॉलम PropertyName और PropertyValue होंगे।

.NET कोड में, हम प्रत्येक कुंजी पढ़ते हैं और तुलनात्मक रूप से टाइप की गई वस्तु से तुलना करते हैं और परिवर्तित करते हैं। कोड वास्तव में गन्दा हो रहा है।

if (qwi.DomainCode == typeof(CoreBO.Base.iQQConstants.MBPCollateralInfo).Name) 
    { 
     if (qwi.RefCode == iQQConstants.MBPCollateralInfo.ENGINETYPE) 
     { 
      Aspiration = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.FUELTYPE) 
     { 
      FuelType = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MAKE) 
     { 
      Make = qwi.Value; 
     } 
     else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MILEAGE) 
     { 
      int reading = 0; 
      bool success = int.TryParse(qwi.Value, out reading); 
      if (success) 
      { 
       OdometerReading = reading; 
      } 
} 
} 

इस स्तंभ उन्मुख डिजाइन के लिए तर्क हम तालिका स्कीमा और संग्रहीत proc बदलने की जरूरत नहीं होगी कि (हम अभी भी इकाई की रूपरेखा के बजाय संग्रहीत proc उपयोग कर रहे हैं) है।

ऐसा लगता है कि हम वास्तविक समस्या में आगे बढ़ रहे हैं। कॉलम उन्मुख डिजाइन उद्योग में अच्छी तरह से स्वीकार किया जाता है।

Answer 1

मुझे आपकी शब्दावली में समस्या हो रही है। आप एक ईएवी संरचना का वर्णन कर रहे हैं (इकाई-विशेषता-मूल्य के लिए खड़े हैं)।

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

एक इकाई-विशेषता-मूल्य डेटाबेस एक इकाई के लिए एक अलग पंक्ति के रूप में प्रत्येक विशेषता को संग्रहीत कर रहा है।

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

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

ओएलटीपी पक्ष पर, आपको एक और समस्या है। जब आप किसी इकाई को सम्मिलित करना चाहते हैं, तो आप आमतौर पर विशेषताओं का एक समूह भी सम्मिलित करना चाहते हैं। एक डालने अब कई प्रविष्टियों में बदल गया है, और आप प्रदर्शन को प्रभावित करने, लेनदेन में इन्हें लपेटना शुरू करना चाहते हैं।

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

Answer 2

स्रोत: विकी

1. कॉलम उन्मुख संगठनों, और अधिक कुशल एक समग्र कई पंक्तियों पर, लेकिन केवल डेटा के सभी स्तंभों की एक विशेष रूप से छोटे सबसेट के लिए गणना की जा करने की जरूरत है जब रहे हैं, क्योंकि पढ़ने कि डेटा के छोटे सबसेट सभी डेटा पढ़ने से तेज़ हो सकता है।
2. कॉलम उन्मुख संगठन अधिक कुशल होते हैं जब कॉलम के नए मान एक ही समय में सभी पंक्तियों के लिए आपूर्ति की जाती हैं, क्योंकि कॉलम डेटा को पंक्तियों के लिए किसी अन्य कॉलम को छूए बिना कुशलतापूर्वक लिखा जा सकता है और पुराने कॉलम डेटा को प्रतिस्थापित किया जा सकता है।
3. पंक्ति उन्मुख संगठन अधिक कुशल होते हैं जब एक ही पंक्ति के कई कॉलम एक ही समय में आवश्यक होते हैं, और जब पंक्ति-आकार अपेक्षाकृत छोटा होता है, क्योंकि पूरी पंक्ति को एक डिस्क खोज के साथ पुनर्प्राप्त किया जा सकता है।
4. पंक्ति-उन्मुख संगठन एक नई पंक्ति लिखते समय अधिक कुशल होते हैं यदि सभी कॉलम डेटा एक ही समय में आपूर्ति की जाती है, क्योंकि पूरी पंक्ति को एक डिस्क खोज के साथ लिखा जा सकता है।

अभ्यास में, पंक्ति-उन्मुख स्टोरेज लेआउट OLTP- जैसे वर्कलोड के लिए उपयुक्त हैं जो अधिकतर इंटरैक्टिव लेनदेन के साथ लोड होते हैं। कॉलम उन्मुख भंडारण लेआउट ओलाप-जैसे वर्कलोड (उदाहरण के लिए, डेटा वेयरहाउस) के लिए उपयुक्त हैं जो आम तौर पर सभी डेटा (संभवतः टेराबाइट्स) पर अत्यधिक जटिल प्रश्नों की एक छोटी संख्या को शामिल करते हैं।

Answer 3

गॉर्डन लिनॉफ की समस्याओं के अलावा समस्याओं के अलावा, ईएवी डेटा मॉडल भी पूछताछ करने के लिए बेहद मुश्किल हैं - सभी कारों को खोजें जहां बीएमडब्ल्यू है और 12 और 24 के बीच के महीनों और लागत < 10000 बुरा एसक्यूएल का एक बड़ा झटका बन गया , विशेष रूप से यदि आप संख्याओं पर स्ट्रिंग तुलना कर रहे हैं ...

Answer 4

आम तौर पर पंक्ति-उन्मुख और स्तंभ-उन्मुख निम्न स्तर (डिस्क) पर स्टोरेज तंत्र है। प्रत्येक भंडारण की भलाई आपकी आवश्यकता पर निर्भर करती है। कुछ परिदृश्य में कॉलम उन्मुख भंडारण बेहतर होगा और कुछ स्थितियों में पंक्ति-उन्मुख इच्छा होगी।

एचबीएएस डेटाबेस में वे स्तंभ-परिवार की अवधारणा का उपयोग कर रहे हैं जो स्तंभों का समूह है।

पंक्ति उन्मुख के बीच का अंतर यह है कि पंक्तियों वाली तार्किक तालिका एक पंक्ति प्रति पंक्ति-ब्लॉक संग्रहीत की जाती है जबकि स्तंभ-उन्मुख स्टोर प्रति कॉलम ब्लॉक में एक कॉलम स्टोर करते हैं।

पंक्ति-उन्मुख परिणाम खराब प्रदर्शन में होते हैं जब हम विश्लेषणात्मक होते हैं (वेतन की राशि, वेतन का औसत) लेकिन जब हमें पंक्ति के आविष्कार विवरण तक पहुंचने या नया रिकॉर्ड डालने की आवश्यकता होती है तो ठीक काम करता है। जबकि स्तंभ-उन्मुख काम विश्लेषणात्मक प्रश्नों पर ठीक काम करते हैं लेकिन परिणामस्वरूप व्यक्तिगत रिकॉर्ड को सम्मिलित करने या पंक्ति के सभी विवरणों तक पहुंचने के लिए खराब प्रदर्शन होता है।

आप इस लिंक पर जा सकते हैं जिसमें विभिन्न परिदृश्यों का वर्णन उनके उदाहरण और उनके सारांश अंतर के साथ होता है।

यहाँ क्लिक करें: http://geekrandomstuff.blogspot.tw/2014/04/row-oriented-database-vs-column.html

Answer 5

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