💞 📎 🤰🏻 रेवेनडीबी का उपयोग करते समय याद रखने योग्य बातें 😀 🎉 😩

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

संक्षिप्त परिचय

रेवेनबेड एक दस्तावेज़-उन्मुख डेटाबेस है। यह समझा जाता है कि यह लचीला, आरामदायक, तेज है और अभी भी इसमें बहुत कुछ अच्छा है ...

और इसलिए यह है।

लेकिन कुछ आरक्षण के साथ।

सबसे महत्वपूर्ण बात

"प्रोजेक्ट आर्किटेक्चर विद रेवेनडीबी" की खोज करते समय पहली चीज जो हमारे सामने आती है, वह है वाक्यांश - एक रिलेशनल डेटाबेस के रूप में रेवेनब के साथ काम न करना। हालाँकि, यह प्रस्ताव किसी भी NoSQL डेटाबेस के साथ काम करने के लिए सही है।

इस वाक्यांश का मतलब है कि आपको डेटा को जहां आवश्यक हो, को अपकृत करने की आवश्यकता है। रेवेनडीबी एक इकाई में सभी आवश्यक जानकारी संग्रहीत करने के निर्णय पर हमें धकेलता है।

एक उदाहरण पर विचार करें।

मान लीजिए हमारे पास निम्नलिखित इकाई है।

public class Article { public long Id {get;set;} public string Title {get;set;} public string Content{get;set;} }

और यह धारणा बनाएं कि हमारे एंटिटी आर्टिकल में टिप्पणियां हो सकती हैं।

 public class Comment { public long Id {get;set;} public string Author {get;set;} public string Content{get;set;} }

डेटाबेस में टिप्पणियों के साथ एक लेख को सही ढंग से लिखने के लिए हमें बस इतना करना है:

लेख वर्ग में टिप्पणियाँ संपत्ति जोड़ें
टिप्पणी से Id गुण निकालें।

दूसरे शब्दों में, हमें टिप्पणियों के लिए एक अलग तालिका रखने की आवश्यकता नहीं है, क्योंकि वे हमेशा एक इकाई के अंदर होती हैं। यही सब के बारे में है।

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

वैसे, रेवेनडीबी में कोई टेबल नहीं हैं। संस्थाओं के संग्रह हैं, और संग्रह से संबंधित इकाई बहुत सरल रूप से सेट की गई है। लेकिन इसके बारे में अधिक नीचे।

मेटाडाटा

यह ध्यान देने योग्य है कि रेवेनडीबी संस्थाओं को JSON ऑब्जेक्ट्स के रूप में संग्रहीत करता है। नतीजतन, उनके पास कुछ सेवा गुणों के अपवाद के साथ, एक विशिष्ट संरचना नहीं है। मुख्य उपयोगिता संपत्ति @metadata है। इस ऑब्जेक्ट में हमारे दस्तावेज़ के सभी नियंत्रण डेटा शामिल हैं: RavenDB के अंदर आईडी, सर्वर पर टाइप करें (हमारा लेख, उदाहरण के लिए), और कई अन्य गुण।

रेवेन-एंटिटी-नाम संपत्ति संग्रह से संबंधित संस्था के लिए जिम्मेदार है। यदि आप इसे बदलते हैं, तो संग्रह जिसमें ऑब्जेक्ट स्थित है, वह भी बदल जाएगा। आईडी स्वचालित रूप से नहीं बदलती है।

वैसे, आइडेंट प्रॉपर्टी में डिफ़ॉल्ट रूप से रेवेनडीबी मैप में आइडेंटिफ़ायर, लेकिन आप किसी भी क्षेत्र को एक पहचानकर्ता बना सकते हैं और पहचानकर्ताओं को उत्पन्न करने के लिए अपनी रणनीति को परिभाषित कर सकते हैं। यहाँ और अधिक विवरण में वर्णित है । आपको बस थोड़ा नीचे स्क्रॉल करना है।

वैसे, महत्वपूर्ण बात ~~जो मैंने पहले कही थी, लेकिन मैं फिर से दोहराता हूं~~ : संस्थाओं के बीच संबंध खराब हैं। इकाई के साथ काम करने वाली हर चीज इसमें होनी चाहिए।
बेशक, एक स्थिति उत्पन्न हो सकती है जब आपको यह निर्धारित करने की आवश्यकता होती है कि क्या एक इकाई दूसरे से संबंधित है, लेकिन अगर आपको लगातार ऐसा करना है, तो अपने आप से पूछें - क्या आप रेवेनडीबी का सही ढंग से उपयोग कर रहे हैं और क्या आपको किसी परियोजना पर इसकी आवश्यकता है?

इकाई खोज

तुच्छ कार्य पर विचार करें - हमें सभी पदों की एक सूची प्राप्त करने की आवश्यकता है।

 List<Blog> blogs = null; using (var session = store.OpenSession()) { blogs = session.Query<Blog>().ToList(); }

इस छोटे से कोड में क्या होता है?
सबसे पहले, हम RavenDB (यह तुच्छ है) के लिए एक कनेक्शन बनाते हैं।
दूसरी बात यह है कि सत्र हमें उन प्रथम संस्थाओं में से 128 प्रदान करता है जो शर्त को पूरा करती हैं। 128 क्यों? क्योंकि यह डिफ़ॉल्ट व्यवहार है। कॉन्फ़िगरेशन में, आप इस मान को 1024 तक बढ़ा सकते हैं, लेकिन, आप देखते हैं, यह आवश्यक व्यवहार नहीं है।

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

वैसे, यहां कोड है (शायद, आपके दृष्टिकोण से, इष्टतम नहीं) जो पृष्ठांकन के साथ काम को सरल करता है।

 public static int GetPageCount<T> (this IRavenQueryable<T> queryable, int pageSize) { if (pageSize < 1) { throw new ArgumentException("Page size is less then 1"); } RavenQueryStatistics stats; queryable.Statistics(out stats).Take(0).ToArray(); //     . var result = stats.TotalResults / pageSize; if (stats.TotalResults % pageSize > 0) //   { result++; } return result; } public static IEnumerable<T> GetPage<T>(this IRavenQueryable<T> queryable, int page, int pageSize) { return queryable .Skip((page - 1)*pageSize) .Take(pageSize) .ToArray(); }

हालाँकि, यह सब नहीं है।
उपरोक्त उदाहरण में, रेवेनडीबी हमें अंतिम संशोधित तिथि द्वारा छांटे गए निकाय देता है। यह @ मेटाडेटा ऑब्जेक्ट में अंतिम-संशोधित संपत्ति है जिसका मैंने पहले उल्लेख किया था।

एक दिलचस्प तथ्य यह है कि आप आईडी से नहीं छाँट सकते। कोई त्रुटि होती है, या कुछ भी नहीं होता है।
समाधान सरल है - एक बनाया क्षेत्र बनाएं और इसके द्वारा सॉर्ट करें।

क्वेरीज़ के लिए रेवेनडीबी का उपयोग करना

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

 private IDocumentSession Session { get { if (_session == null) { _session = _store.OpenSession(); } if (_session.Advanced.NumberOfRequests == _session.Advanced.MaxNumberOfRequestsPerSession) { _session.Dispose(); _session = _store.OpenSession(); } return _session; } }

एक परियोजना में रेवेनडीबी का उपयोग करना

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

मेरा समाधान एक रेवेनडीबी सत्र पर प्रॉक्सी करना है, जो मुझे चाहिए।
इस घटक को बनाने का मुख्य कारण सत्र मॉक के साथ कठिनाई है। यदि लोड अभी भी किसी भी तरह से डुबोया जा सकता है, तो क्वेरी लगभग अवास्तविक है। जबकि ऐड-इन बहुत सरल है।

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