2010-12-29 9 views
6

एंड्रॉइड क्लास SQLiteOpenHelper के पास एक पठनीय डेटाबेस के साथ-साथ पढ़ने और लिखने योग्य डेटाबेस को वापस करने का एक तरीका है। वर्तमान में मैं केवल लेखन योग्य डेटाबेस का उपयोग कर रहा हूं और इसमें कोई समस्या नहीं है लेकिन मैं सोच रहा हूं कि केवल पढ़ने योग्य उपयोग करने के लिए लाभ क्या होगा यदि मैं केवल एक एसिंक कार्य (या गतिविधि) में पढ़ रहा हूं।पठनीय SQLite डेटाबेस का उपयोग करने के कारण

प्रदर्शन लाभ हो सकते हैं लेकिन मैंने वास्तविक संख्याओं का कोई संदर्भ नहीं देखा है। अगर मैं पठनीय और लिखने योग्य के बीच स्विचिंग करता हूं तो परिवर्तन में एक ओवरहेड होता है जो सभी प्रदर्शन लाभ को दूर ले सकता है।

क्या किसी के पास कोई वास्तविक संख्या या अनुभव है? क्या यह अलग-अलग पहुंच को लागू करने योग्य है?

+1

मैंने आमतौर पर इसे प्रदर्शन की तुलना में सुरक्षा उपाय के रूप में व्याख्या की है। कोई भी सभी जावा कक्षाओं/विधियों/डेटा सदस्यों को सार्वजनिक घोषित कर सकता है, लेकिन हम खुद को खराब करने से रोकने के लिए 'संरक्षित', 'निजी', और पैकेज-संरक्षित 'का उपयोग करते हैं। इसी प्रकार, एक पठनीय डेटाबेस कोडिंग त्रुटियों को पकड़ने में मदद कर सकता है। ऐसा कहा जा रहा है, चूंकि 'SQLiteOpenHelper' भविष्य में 'getWritableDatabase()' कॉल पर लिखने योग्य डेटाबेस को" अपग्रेड "करता है, तो मान शायद कुछ हद तक सीमित है। – CommonsWare

+0

उस संकेत के लिए धन्यवाद। मुझे लगता है कि मैं नीचे बताए अनुसार इस चरण में परेशान नहीं होने जा रहा हूं। –

उत्तर

5

मैं प्रदर्शन लाभों पर टिप्पणी नहीं कर सकता लेकिन मैं हमेशा किसी भी 'डेटा' तक पहुंच के लिए 'अच्छा अभ्यास' (या 'सर्वोत्तम अभ्यास') के सिद्धांत पर काम करने की कोशिश करता हूं। स्रोत (पाठ फ़ाइलें, डीबी या जो कुछ भी)।

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

दो उदाहरण मैं के बारे में सोच सकते हैं ...

  1. एक बाहरी प्रक्रिया को बनाए रखने के डेटा की जिम्मेदारी हो सकता है तो यह रखरखाव चरण के दौरान किसी भी अन्य प्रक्रिया द्वारा 'पढ़ने' पहुंच के अलावा सभी को अवरुद्ध करता है। इस मामले में, पर आपके कोड को पहुंच से वंचित कर दिया जाएगा यदि आप पर पहुंच/लिखने का अनुरोध करते हैं तो यह आवश्यक नहीं है।
  2. डेटा अखंडता समझौता करने का जोखिम - बाहरी दुनिया से सिस्टम में हैक्स को आंतरिक कोड का उपयोग करके सुरक्षा छेद के माध्यम से हासिल किया जा सकता है, जिसने डेटा को पढ़ने/लिखने के लिए डेटा को पढ़/लिखने के लिए वास्तव में केवल 'पढ़ने' पहुंचने की आवश्यकता होती है।

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

+0

जबकि मैं आपके अंक से सहमत हूं, वे इस उदाहरण में एंड्रॉइड पर लागू नहीं होते हैं। इस तरह के कोई डीबी सर्वर नहीं है, बल्कि एक अद्वितीय डीबी फ़ाइल और एक्सेस कोड (नाइटवे और दल्विक वीएम के माध्यम से) जो इस एप्लिकेशन के लिए अद्वितीय है। प्रत्येक ऐप के भीतर डीबी एक्सेस अनन्य (लागू) और अनुक्रमिक है। यदि किसी अन्य ऐप में डीबी है तो यह एक अलग डीबी फ़ाइल है और एक्सेस के लिए बहिष्करण है और सभी (प्रत्येक ऐप का अपना वीएम है)। जैसा कि आपने दूसरी टिप्पणी में ऊपर देखा था, जावाडोक भी कहता है कि वही वस्तु वापस आती है, इसलिए यह सब कम समझ में आता है .. –

+0

@ मैनफ्रेड मोज़र: हाँ, मुझे पता है कि ऐप्स अपने स्वयं के वीएम के भीतर मौजूद हैं और मैं हूं SQLite के साथ काफी परिचित कोई सर्वर नहीं है (मैं अब कुछ प्लेटफार्मों पर SQLite का उपयोग कर रहा हूं)। क्या सभी SQLite डीबीएस 'इन-प्रोसेस' मौजूद हैं? उदाहरण के लिए एसडी कार्ड पर बनाए जा सकने वाले लोगों के बारे में क्या? साथ ही, एक ही ऐप के भीतर अन्य धागे से पहुंच के बारे में क्या? CommonsWare की टिप्पणी के बारे में हम सब कुछ 'सार्वजनिक' के रूप में नहीं बनाते हैं, मूल रूप से मेरा मतलब था - 'सर्वोत्तम अभ्यास' और वह सब। कभी नहीं मानें कि आपका 'क्षेत्र' कभी नहीं बदलेगा। – Squonk

+0

मैं इस चरण में आपका उत्तर स्वीकार करने जा रहा हूं। इस स्तर पर मुझे संदेह है कि मैं इसे फिर से प्रतिक्रिया देने का प्रयास करूंगा क्योंकि मेरे मामले में मुझे लगता है कि निरंतर समापन और उद्घाटन प्रदर्शन को कम करेगा। सुरक्षा के मामले में मुझे कोई मूल्य नहीं दिखता है क्योंकि डेटा गैर महत्वपूर्ण है। –

6

अच्छा सवाल। मुझसे कोई संख्या नहीं (SQLLiteOpenHandler जावाडोक से)

"यह (getReadableDatabase) निकटतम विवरण एक ही वस्तु getWritableDatabase() द्वारा दिया हो जाएगा जब तक कि कुछ समस्या है, इस तरह एक पूर्ण डिस्क के रूप में, डेटाबेस केवल पढ़ने के लिए खोले जाने के लिए की आवश्यकता है। में उस स्थिति में, केवल पढ़ने-योग्य डेटाबेस ऑब्जेक्ट वापस कर दिया जाएगा। यदि समस्या ठीक हो गई है, तो प्राप्त करने के लिए एक भविष्य कॉल WitableDatabase() सफल हो सकता है, जिस स्थिति में केवल-पढ़ने के लिए डेटाबेस ऑब्जेक्ट बंद हो जाएगा और पढ़ने/लिखने की वस्तु वापस कर दी जाएगी भविष्य में। "

+0

अच्छा लगता है और मेरे उत्तर में उल्लेख किए गए पहले बिंदु पर विफलता को रोकने के लिए कुछ रास्ता तय करेगा। – Squonk

+0

@ मैनफ्रेड मोज़र जैसा कि मेरे उत्तर में कहा गया है .... सुनिश्चित नहीं है कि हम इसे एक या दूसरे तरीके से साबित कर सकते हैं (यानी पासफ लाभ नहीं मिला है)। यहां एक (असत्यापित) कारण है जो मैं सोच सकता हूं कि इसका एक प्रभाव पड़ सकता है। यदि आप getWritableDatabase() का उपयोग करते हैं तो आपको क्लोज़() विधि को कॉल करने की आवश्यकता है या अन्यथा आपको LogCat में बहुत लाल मिलता है। जहां (यह हिस्सा असत्यापित है) getReadableDatabase() कॉल को विधि बंद करने के लिए जरूरी नहीं है()। यदि आपका एप्लिकेशन अक्सर डेटाबेस बंद कर रहा है, तो यह प्रदर्शन को प्रभावित कर सकता है (!)। – GSree

संबंधित मुद्दे