"ओपन स्कीमा" के साथ डेटाबेस - अच्छा या बुरा विचार?

Question

रेडडिट के सह-संस्थापक ने लाखों उपयोगकर्ताओं को स्केल करते समय उनके मुद्दों पर एक प्रस्तुति दी। सारांश here उपलब्ध है।

बजाय, वे एक बात टेबल और एक डेटा तालिका रखें:

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

यह मेरे लिए एक भयानक विचार जैसा प्रतीत होता है, लेकिन ऐसा लगता है कि रेडडिट के लिए काम किया है। क्या यह सामान्य रूप से एक अच्छा विचार है, यद्यपि? या क्या यह रेडडिट की एक विशिष्टता है जो उनके लिए काम करने के लिए हुई?

Answer 1

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

Answer 2

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

Answer 3

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

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