2009-12-02 24 views
6

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

मुझे शॉपिंग साइटों के लिए कुछ जवाब मिले जहां फ़ील्ड का निर्णय नहीं लिया गया: एक लंबवत डेटाबेस संरचना का उपयोग किया जाना चाहिए। लेकिन मैं इस बारे में उलझन में हूं कि परिवार के पेड़ की साइट के लिए क्या उपयोग करना है। क्या मुझे लंबवत या क्षैतिज का उपयोग करना चाहिए?

उत्तर

8

मुझे लगता है कि आप भंडारण के लिए माइस्क्ल, एमएस एसक्यूएल, स्क्लाइट, पोस्टग्रेस्क्ल या ओरेकल जैसे रिलेशनल डेटाबेस का उपयोग करते हैं?

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

मैं एक 'क्षैतिज' तालिका का उपयोग करता हूं, न कि एक इकाई-attribyte-value-system (लंबवत तालिका)। लंबवत तालिका प्रणाली धीमी होती है। उन्हें उचित रूप से अनुक्रमित नहीं किया जा सकता है और क्वेरी ऑप्टिमाइज़र को भ्रमित नहीं किया जा सकता है।

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

+0

मैं एसक्यूएल सर्वर 2008 का उपयोग कर रहा हूं। और उपयोगकर्ता को नई गुण जोड़ने की अनुमति नहीं होगी। – Radhi

0

मैं tuinstoel से सहमत हूं, लंबवत तालिका/ईएवी प्रणाली न केवल धीमी है बल्कि कुछ समय जटिल भी है। कभी-कभी आपको अपनी कुछ एपीआई विधियों को लिखना आवश्यक होता है जो उन तालिकाओं और डेवलपर्स से निपटने के लिए जटिलता से बचने के लिए केवल उन तरीकों से निपटते हैं।

तो यदि आपको अधिक फ़ील्ड जोड़ने की आवश्यकता नहीं है तो क्षैतिज तालिका के साथ रहें। हालांकि यदि आप बहुभाषी क्षमता का समर्थन करने जा रहे हैं तो भी आपको अलग-अलग तालिका की आवश्यकता हो सकती है। लेकिन मैं अभी भी क्षैतिज तालिकाओं के साथ चिपकने की सलाह देते हैं।

मैं उपयोगकर्ता प्रोफ़ाइल को शामिल करने वाली साइट भी विकसित कर रहा हूं और मैं क्षैतिज तालिकाओं का उपयोग कर रहा हूं और यदि भविष्य में अलग-अलग भाषाओं का समर्थन आवश्यक होगा तो मैं केवल उन क्षेत्रों के लिए संशोधित करूंगा जहां भाषा महत्वपूर्ण होगी।

3

लंबवत डेटाबेस detawarehousing और पढ़ने/केवल रिपोर्टिंग के लिए महान हैं। आम तौर पर आप उन्हें रातोंरात फिर से उत्पन्न करते हैं। उनका लेखन प्रदर्शन आमतौर पर बहुत बुरा होता है हालांकि चयन 10-100 गुना तेजी से होते हैं।

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

आपका मामला एक लंबवत डेटाबेस के लिए एक अच्छा उम्मीदवार प्रतीत नहीं होता है।