Android डेटाबेस डिजाइन के तरीके

एक Android डेवलपर के रूप में, मुझे मोबाइल एप्लिकेशन में डेटाबेस डिजाइन करने के लिए दो अलग-अलग तरीकों का सामना करना पड़ा। शायद यहाँ प्रस्तुत कथन किसी को स्पष्ट प्रतीत होगा, या शायद यह किसी को एक नया विचार देगा या गलतियों से बचाएगा। सामान्य तौर पर, एक लंबे परिचय के बिना हम व्यवसाय के लिए नीचे उतरते हैं ...

समस्या पर दो विचार

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

हम यहां मोबाइल प्लेटफार्मों की बहुत सीमित हार्डवेयर क्षमताओं को जोड़ते हैं, विशेष रूप से रैम की एक छोटी मात्रा में। यह पहले से ही पर्याप्त नहीं है, इसलिए इसके अलावा, एंड्रॉइड ओएस संस्करण के आधार पर 16 से 48 एमबी तक उपलब्ध रैम प्रति प्रक्रिया की मात्रा को सीमित करता है। और इन कुछ मेगाबाइट्स में से, DBMS को केवल एक अंश ही मिलता है, क्योंकि इसमें एप्लिकेशन भी है। खैर, निष्कर्ष में, SQLite, इसकी विशेषताओं को देखते हुए, लेनदेन के अलगाव के केवल दो स्तरों का समर्थन करता है। वे या तो क्रमबद्ध या पूरी तरह से अक्षम हैं!

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

आइए पूरी स्पष्टता के लिए एक उदाहरण पर विचार करें। जावा कोड में हमारे डेटा मॉडल को इस तरह देखें:

class Group { private Long _id; private String number; private List<Student> students; // getters and setters ... } class Student { private Long _id; private String name; private String surname; private Group group; // getters and setters ... } 

इस प्रकार, "मानक" संस्करण में, हमें विशेषताओं के संगत सेट के साथ दो टेबल मिलते हैं।

 create table Group( _id primary key integer autoincrement, number text); create table Student( _id primary key integer autoincrement, name text, surname text, group_id integer foreign key); 

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

कुंजी-मूल्य दृष्टिकोण को लागू करते समय, तालिकाएं इस तरह दिखेंगी

 create table Group( _id primary key integer autoincrement, value blob); create table Student( _id primary key integer autoincrement, value blob, group_id integer foreign key); 

एक ही समय में, समूहों और छात्रों को अलग-अलग तालिकाओं के अनुसार अलग-अलग क्रमबद्ध किया जाता है। या आम तौर पर इस तरह:

 create table Group( _id primary key integer autoincrement, value blob); 

जब एक समूह को सीधे एक तालिका में सभी छात्रों के साथ क्रमबद्ध किया जाता है।
दोनों तरीकों के फायदे और नुकसान पर विचार करें और इससे क्या लाभ हो सकते हैं।

दृष्टिकोण, पेशेवरों और विपक्ष की तुलना

रिलेशनल बीजगणित की विशेषताएं

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

DB फ़ाइल का आकार

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

डेटाबेस स्कीमा बदलते समय लचीलापन

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

इकाई उदाहरणों तक पहुंच का सिंक्रनाइज़ेशन

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

उत्पादकता

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

कोड मात्रा

मानक दृष्टिकोण में, SQL कोड की मात्रा, डेटाबेस स्कीमा, प्रश्नों और स्थितियों को बनाने और संशोधित करने के लिए विभिन्न स्क्रिप्ट, DAO ऑब्जेक्ट्स आदि में वृद्धि होती है। की-वैल्यू में, इस तरह के कोड की मात्रा कम हो जाती है, लेकिन कोड की मात्रा जो विभिन्न सॉर्टिंग, ग्रुपिंग और फ़िल्टरिंग को शर्तों के अनुसार बढ़ा रही है, क्योंकि यह सब "मैन्युअल रूप से" किया जाना है, जब डीबीएमएस मानक दृष्टिकोण में करता है, और हमें केवल आवश्यक क्वेरी लिखना होगा।

क्रमबद्धता

कुंजी-मूल्य दृष्टिकोण के माइनस में मानक जावा क्रमांकन / डीरिएलाइज़ेशन के उपयोग से जुड़े प्रदर्शन में गिरावट हो सकती है, जो कि आप जानते हैं, बहुत तेज़ नहीं है। यहां, एक विकल्प के रूप में, आप इस समस्या को हल करने वाले पुस्तकालयों में से एक का उपयोग कर सकते हैं, उदाहरण के लिए, Google से प्रोटोबॉफ़। गति के अलावा, एक अतिरिक्त प्लस, प्रोटोबॉफ का उपयोग करने के मामले में, जैसा कि संस्करण है यह प्रोटोकॉल वस्तुओं के संस्करण का समर्थन करता है।

निष्कर्ष

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