क्या SQLite को थोड़ा कम नहीं आंका गया है? [बन्द है]


15

इससे पहले कि मैं प्रश्न पूछूं, पहले मुझे SQLite के बारे में अपने विचारों का वर्णन करने दें।

मैं ऐसे उपकरण पसंद करता हूं जो छोटे, तेज और अधिक महत्वपूर्ण हैं, केवल वास्तव में आवश्यक कार्यक्षमता है। इसलिए मुझे SQLite पसंद है और मुझे MS-SQL थोड़ा कम पसंद है।

उदाहरण के लिए: MS-SQL में बहुत अधिक कार्यक्षमता, मापनीयता, आदि हो सकते हैं, लेकिन यदि आप अशुभ हैं, तो इसे स्थापित करने के लिए दर्द भी हो सकता है। बेशक, मैं यह नहीं कह रहा कि एक कठिन स्थापना एक विशेष डेटाबेस का चयन न करने का एक कारण है।

मुझे गलत न समझें: MS-SQL एक उत्तम गुणवत्ता वाला उत्पाद है। मैं MS-SQL के साथ बहुत अनुभवी हूं; मैं एक पेशेवर के रूप में उत्पाद को बहुत अच्छी तरह से समझता हूं। मैं इसे कुछ परिस्थितियों में कम पसंद करता हूं, जहां इसकी वास्तव में जरूरत नहीं है (= कई उपयोगकर्ता नहीं, <10-15)।

डेटाबेस की कार्यक्षमता का आप वास्तव में कितना उपयोग करते हैं? मेरे अनुभव में यह अक्सर सामान्य एसक्यूएल (चयन, INSERT और अद्यतन) है।

मुझे SQLite पसंद है। मोहक तेज है। "इंस्टॉल" करना बेहद आसान है। मुझे लगता है कि SQLite जितना दावा कर सकती है, उससे अधिक कर सकती है। केवल एक-प्रक्रिया / एकल उपयोगकर्ता अनुप्रयोगों के लिए इसका उपयोग क्यों करें? सब के बाद: नहीं कई अनुप्रयोगों लगातार एक डेटाबेस का उपयोग कर रहे हैं।

उदाहरण के लिए: 15 उपयोगकर्ताओं के साथ, ईआरपी एप्लिकेशन पर विचार करें। उसके लिए SQLite का उपयोग क्यों नहीं किया जा सकता है? आइए इसका सामना करते हैं: मेरे पेशेवर अनुभव में इस तरह के एप्लिकेशन के अधिकांश उपयोगकर्ता डेटाबेस का उपयोग उस कुल समय के लगभग 5-10% के लिए करेंगे जो वे एप्लिकेशन का उपयोग कर रहे हैं। अन्य 90-95% में वे केवल स्क्रीन पर जानकारी देख रहे हैं, एक ग्रिड / फॉर्म में डेटा दर्ज कर रहे हैं और जब वे अपने इनपुट को बचाते हैं तो यह डेटाबेस के 1 सेकंड से अधिक नहीं होता है। Fe: 1,5 मिनट का इनपुट समय बनाम समय की बचत का 1 सेकंड।

यदि SQLite डेटाबेस फ़ाइल "सेविंग टाइम" के दौरान लॉक हो जाती है, तो अन्य उपयोगकर्ताओं को डेटाबेस तक पहुंचने की आवश्यकता होती है, लेकिन वे इस बात पर ध्यान नहीं देते हैं क्योंकि प्रतीक्षा समय बहुत छोटा होगा (ध्यान नहीं देने योग्य)। कोड में आपको केवल अपवादों से बचने के लिए डेटाबेस के संभावित "व्यस्त" समय से निपटना होगा, लेकिन ऐसा करना मुश्किल नहीं है।

कुछ लोग, जिन्हें मेरे जैसा ही सोचना चाहिए, ने भी SQLite के लिए एक क्लाइंट-सर्वर समाधान बनाया है: SQLitening । इससे मुझे यकीन हो गया कि मैं खुद को बेवकूफ नहीं बना सकता।

बेशक वहाँ डेटाबेस गहन अनुप्रयोग हैं जहाँ SQLite फिट नहीं है। लेकिन जैसा कि मैं अब इसके बारे में सोचता हूं, कई बहु-उपयोगकर्ता अनुप्रयोग, यदि वे 15 उपयोगकर्ता या उससे अधिक नहीं हैं, तो SQLite के साथ ठीक करना चाहिए।

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

FYI करें: मेरे पेशे में हम ग्राहकों को उत्पाद बेचते हैं (कस्टम और मानक, ज्यादातर ईआरपी संबंधित), जहां औसतन, 5-6 से अधिक लोग उत्पाद का उपयोग नहीं करेंगे। कुछ अपवाद हैं, लेकिन 10-15 से अधिक उपयोगकर्ता नहीं हैं।

प्रश्न यह है कि क्या मैं यह सोचने में सही हूं कि मैं उदाहरण के लिए कुछ बहु-उपयोगकर्ता एप्लिकेशन के लिए SQLite का उपयोग कर सकता हूं जैसे मैं वर्णन करता हूं? क्या कोई तकनीकी नुकसान हैं, जिनके बारे में मुझे पता होना चाहिए? आपके अनुभव (नकारात्मक या सकारात्मक) क्या हैं जो मुझे सही विकल्प बनाने में मदद करेंगे?

अद्यतन: कृपया इसे अन्य डेटाबेस के नकारात्मक निर्णय के रूप में न देखें। वे ज्यादातर सभी ठीक उत्पाद हैं। बस यहाँ मेरे विचारों को साझा करना और इस बारे में आपकी राय में दिलचस्पी।


9
क्षमा करें, लेकिन "क्या मैं सही हूं?" एक सवाल में शेख़ी नहीं है।
पीडीआर

1
@pdr: आप इसे शेख़ी क्यों मानते हैं? मैं MS-SQL या अन्य डेटाबेस को नकारात्मक रूप से नहीं आंक रहा हूं; वे ज्यादातर सभी ठीक उत्पाद हैं। मैं सिर्फ अपने विचार साझा कर रहा हूं और अन्य साथी प्रोग्रामर की राय सुनने के लिए इच्छुक हूं। न कुछ ज्यादा, न कुछ कम।

3
वहाँ कोई सवाल नहीं है, केवल मान्यता के लिए एक खोज। एफएक्यू से: "आपको केवल वास्तविक समस्याओं के आधार पर व्यावहारिक, उत्तर देने योग्य प्रश्न पूछना चाहिए जो आपके सामने आते हैं। चेट्टी, खुले-समाप्त प्रश्न हमारी साइट की उपयोगिता को कम करते हैं और अन्य प्रश्नों को सामने वाले पृष्ठ से दूर करते हैं।" programmers.stackexchange.com/faq
pdr

1
@pdr: मैं समझता हूँ कि, लेकिन मैं ईमानदारी से यहाँ एक सवाल पूछना चाहता था। शायद मैं स्पष्ट नहीं था, इसलिए मैंने इस सवाल पर फिर से विचार किया।

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

जवाबों:


8

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

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

स्केलेबिलिटी / ओवर-इंजीनियरिंग के लिए हमेशा चिंता का विषय है। भले ही उपयोगकर्ताओं या डेटा की मात्रा अभी भी प्रबंधनीय है, किसी को हमेशा कुछ इंट्रानेट या अन्य वेबसाइट / ब्राउज़र इंटरफ़ेस पर लाइव डेटा का उपयोग करने का विचार है। फ़ाइल डेटाबेस समस्याएँ प्रस्तुत करते हैं। यह केवल एक व्यक्ति को लेता है जो आपको एक 'स्केलिंग' समस्या देने के लिए एक वीपीएन (ऐप को उनके लैपटॉप पर स्थापित किया गया है) पर डेटा फ़ाइल तक पहुंचना चाहता है। आप डिस्कनेक्ट किए गए उपयोगकर्ताओं के लिए अनुमति देने के लिए ऐप बना सकते हैं जो वापस लौटने पर सिंक-अप कर सकते हैं। बस कभी-कभी कार्यालय के बाहर के उपयोगकर्ता के लिए इसके लायक नहीं लगता है।


आप SQL सर्वर कॉम्पैक्ट संस्करण के लिए एक ही तर्क कर सकते हैं, लेकिन एक MS एक्सेस डेटाबेस के लिए नहीं । एक्सेस डेटाबेस के साथ ऐसा व्यवहार किया जाता है जैसे वे एक वास्तविक डेटाबेस हैं, लेकिन साझा फ़ाइलों की तरह अधिक काम करते हैं। वे एक नाजुक समाधान हैं; SQL सर्वर कॉम्पेक्ट वास्तव में एक बेहतर, तेज़, अधिक विश्वसनीय विकल्प है जो अभी भी एक्सेस फ़्रेंड्स के साथ काम करता है। मुझे संदेह है कि SQLite एक्सेस डेटाबेस की तुलना में काफी अधिक टिकाऊ है, भले ही यह तकनीकी रूप से एक साझा फ़ाइल समाधान है।
रॉबर्ट हार्वे

@RobertHarvey - हमारी व्यावसायिक माँगें हैं जहाँ MS Access 10 वर्षों के लिए पर्याप्त (यानी एक्सेल से बेहतर) समाधान रहा है। जब कोई बड़ी बात हो जाती है, तो हमें कुछ न कुछ करना पड़ता है। एक्सेस स्किल वाले पावर यूजर्स को खोजने और उत्तोलन करने में बहुत आसान है। कार्यक्षमता को एक निश्चित तारीख तक होना है, लेकिन हम भाग्यशाली हैं कि स्केलेबिलिटी, प्रदर्शन, डेटा वृद्धि और सुरक्षा कभी एक कारक नहीं रहे हैं। अपग्रेड करना, अब यह एक अलग कहानी है।
जेएफओ

मुझे गलत मत समझो; मुझे लगता है कि प्रवेश महान है। लेकिन SQL सर्वर कॉम्पेक्ट किसी भी नए एक्सेस एप्लिकेशन के लिए मेरी न्यूनतम बैकएंड आवश्यकता होगी जहां उपयोगकर्ता डेटा साझा करते हैं।
रॉबर्ट हार्वे

@RobertHarvey - मुझे उस पर गौर करना होगा। धन्यवाद
JeffO

12

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

एक और उपयोग जो मैं देख रहा हूं: जब आपके पास केवल एक उपयोगकर्ता है। हाँ, यह संभव है, उदाहरण के लिए "फ़ायरफ़ॉक्स" या "ओपेरा" सोचें :-)

इसके अलावा, SQLite वेबसाइट पर वे इस बारे में बहुत ईमानदार हैं और इसका उपयोग न करने का कारण देते हैं ( आईटी "पैराग्राफ" जहां एक और RDBMS मई बेहतर काम कर सकते हैं "पैरा देखें)

पीएस: एसक्यूएल सर्वर एक्सप्रेस पर टिप्पणियों से संबंधित है, हाँ इसे "स्थापित" करने की आवश्यकता है। और मुझे इसे व्यक्तिगत रूप से अपडेट करने में कुछ परेशानी हुई (मुझे 2008 R2 को स्थापित करने में सक्षम होने के लिए पिछले संस्करण से संबंधित कुछ रजिस्ट्री कुंजियों को मैन्युअल रूप से हटाना पड़ा)। हालाँकि, यदि आप Microsoft द्वारा विकसित डेटाबेस में SQLite की तुलना करना चाहते हैं, तो Sql सर्वर कॉम्पैक्ट संस्करण को देखें , जिसे आपको इंस्टॉल करने की आवश्यकता नहीं है ("निजी-फ़ाइल आधारित तैनाती" देखें)।


मैंने सीई को देखा, लेकिन किसी तरह ऐसा लगता है कि SQLite बेहतर / तेज / आसान है। यकीन के लिए पता नहीं है, मैं सुनिश्चित करने के लिए पर्याप्त सीई का इस्तेमाल / परीक्षण नहीं किया।

5

उदाहरण के लिए: 15 उपयोगकर्ताओं के साथ, ईआरपी एप्लिकेशन पर विचार करें। उसके लिए SQLite का उपयोग क्यों नहीं किया जा सकता है?

बहुत कम एप्लिकेशन में कुछ उपयोगकर्ता हमेशा के लिए होते हैं। और अधिक उपयोगकर्ताओं को देखने के लिए कुछ के लिए, और अधिक जटिल डेटा हेरफेर, SQLite का उपयोग प्रदर्शन के कारणों के लिए पूरी तरह से सवाल से बाहर है सरल "एक समय में एक लेनदेन लिखें" लॉकिंग मॉडल के कारण।

मान लीजिए कि आपके पास 100 उपयोगकर्ता हैं, प्रत्येक 60 सेकंड के लिए काम कर रहा है और एक फॉर्म भर रहा है और फिर उसे सबमिट कर रहा है। इसलिए आपको प्रति सेकंड 1.6 लेनदेन की प्रक्रिया करने की आवश्यकता है। डेटा मॉडल जटिल है और एक फॉर्म को सहेजने में कई बड़ी तालिकाओं से पढ़ना और लिखना शामिल है, शायद एक अलग प्रणाली के साथ संवाद भी कर रहा है, इसलिए प्रत्येक लेनदेन में 2 सेकंड लगते हैं "फ़ॉर्म सबमिट करें" परिणाम। लेकिन SQLite लेनदेन को समवर्ती रूप से संसाधित नहीं कर सकता है, इसलिए इसका मतलब है कि यह प्रति स्कैंड प्रति 0.5 लेनदेन की प्रक्रिया कर सकता है। उफ़।

"स्थापित करने के लिए दर्द हो सकता है" बुनियादी ढांचे के एक महत्वपूर्ण टुकड़े के खिलाफ निर्णय लेने का एक अच्छा कारण नहीं है। इसके अलावा, चुनने के लिए अन्य DB इंजन हैं, जिनमें से कम से कम दो (MySQL और Postgres) स्वतंत्र हैं और इनमें SQLite की संगामिति सीमाएँ नहीं हैं। MS-SQL की तुलना में उन्हें स्थापित करना और भी आसान हो सकता है।


मैं समझता हूं और सहमत हूं। लेकिन मेरे पेशे में मेरे पास ऐसे ग्राहक नहीं हैं जो 10 से अधिक लोगों के साथ हमारे उत्पादों (मानक और कस्टम, ज्यादातर ईआरपी संबंधी) का उपयोग करते हैं। औसतन इसके 5-6 उपयोगकर्ता भी हैं। मैं अपने सवाल पर फिर से विचार करूंगा।

4
@Marcus V: सवाल यह है कि यदि कोई ग्राहक बहुत बड़ा हो गया है और पाता है कि आपके द्वारा बनाया गया ऐप उपयोग करने में धीमा हो गया है, और आप उन्हें इसका कारण बताते हैं कि DBMS उस कई उपयोगकर्ताओं को नहीं संभाल सकता है, और वे पूछते हैं " आपने एक बेहतर DBMS का उपयोग क्यों नहीं किया ", आपको क्या लगता है कि उत्तर" जिन्हें स्थापित करना कठिन है "को पुनः प्राप्त किया जाएगा? मैं आपको बता सकता हूं कि मेरी प्रतिक्रिया क्या होगी: मुझे लगता है कि "यह एक शौकिया है। मुझे अपना सॉफ़्टवेयर लिखने के लिए किसी और को खोजने की आवश्यकता है"।
माइकल बोर्गवर्ड

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

जो उपयोगकर्ता एप्लिकेशन को आगे बढ़ाने के बारे में गलत तरीके से रोता है, उसे संभवतः उपयोगकर्ता सीमाओं के बारे में सूचित किया गया था लेकिन उसने सस्ता रास्ता चुना। यह इंटिअल सेटअप पर सब ठीक है, लेकिन वे कितने खुश होंगे जब आपको उन्हें नए सर्वर पर स्थापित करने के लिए एक और शुल्क देना होगा, जब वे सिर्फ एक फाइल की नकल कर सकते थे?
जेफो जूल

1
@ जेफ ओ: मुझे लगता है कि आपने मेरे इरादों को गलत समझा। मैं SQLite नहीं चुन रहा हूँ क्योंकि यह मुफ़्त, सस्ता और / या स्थापित करने में आसान है। मैं इसे केवल इसलिए चुनूंगा क्योंकि यह छोटा, तेज और संसाधन अनुकूल है। तो यह मुख्य रूप से व्यावहारिक / तकनीकी कारणों से है। हमारे कई ग्राहक हार्डवेयर पर ज्यादा खर्च नहीं करते हैं, इसलिए मैं अक्सर इस (एक्सचेंज, एसक्यूएल, आदि) पर सब कुछ के साथ एक एकमात्र सर्वर का सामना करता हूं और इसके कारण लगभग "सांस से बाहर" होते हैं। अगर मैं ऐसे उत्पाद का वितरण कर सकता हूं जो उच्च प्रणाली की आवश्यकताओं को पूरा नहीं करता है, तो मेरा ग्राहक खुश होगा। SQLite कोई वजन नहीं जोड़ता है, MSSQL करता है।

4

मुझे लगता है कि SQLLite अनुप्रयोग विकास के लिए उत्कृष्ट है, यह सबसे बड़ी ताकत है कि इसे क्लाइंट पर स्थापित करने की आवश्यकता नहीं है।

हालाँकि, SQL सर्वर एक्सप्रेस को कम मत समझो, यह सामान्य एसक्यूएल सर्वर की अधिकांश विशेषताओं के साथ एक नि: शुल्क उत्कृष्ट डेटाबेस है, जिसमें केवल डेटाबेस आकार में एक सीमा है (जो कि अधिक से अधिक कठिन है) साथ में सामान्य के उत्कृष्ट उपकरणों का उपयोग करने की क्षमता है एस क्यू एल सर्वर।

यह सबसे बड़ा नकारात्मक पक्ष यह है कि आपको इसे स्थापित करने की आवश्यकता है, मैं उस हिस्से के बारे में थोड़ा अनिश्चित हूं, हालांकि अब चारों ओर एक रास्ता हो सकता है


2
आप सही हे। MS-SQL एक्सप्रेस एक उत्तम गुणवत्ता वाला उत्पाद है। यह सिर्फ इतना है कि मैं इसे थोड़ा फूला हुआ और बहुत अधिक संसाधनों का उपयोग कर रहा हूं। आजकल पीसी / सर्वरों में कोई समस्या नहीं है। मैं सिर्फ और पुराने स्कूल का व्यक्ति हूं जो अभी भी सोचता है कि अधिक शक्तिशाली हार्डवेयर का मतलब यह नहीं है कि मुझे संसाधनों की उपेक्षा / बर्बाद करना चाहिए अगर मैं इससे बच सकता हूं। कम बेहतर है ...;)।

2
डीबी इंजन वाला डेटाबेस डिस्क से पढ़ने / लिखने के बजाय मेमोरी को कैशिंग करके एक्सेस को ऑप्टिमाइज़ कर सकता है। लेकिन मैं एसक्यूएल लाइट की तरह इन-प्रोसेस डीबी के लिए प्रदर्शन के बारे में निश्चित नहीं हूं
सार

1
@ सैराट: अफाक एसोलाइट मेमोरी कैश का गहनता से उपयोग करता है।

2

यदि आप हर घंटे कुछ GB डेटा के साथ काम कर रहे हैं तो मैं SQLite को एक गंभीर डेटाबेस नहीं मानता। यह दर्दनाक रूप से धीमा हो जाता है और पूरे एप्लिकेशन के प्रदर्शन को नीचे लाता है। क्षमा करें, लेकिन मैं SQLite के लिए आपके आकर्षण से सहमत नहीं हूं :-)


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

डेटा ussage के बारे में यह एक बड़ा अगर है।
जेफ

@ जेफ ओ: राइट। अगर उपयोगकर्ताओं की संख्या अपेक्षाकृत कम है (<10-15) और डेटा की कुल मात्रा अधिक नहीं है तो मैं केवल SQLite का चयन करूंगा। हमारे अनुभव में कुल डेटाबेस का आकार अक्सर 300-400 एमबी और लगभग कभी नहीं> 1 जीबी है।

1

डेटाबेस के साथ समस्या यह है कि वे अधिक से अधिक डेटा जमा करते हैं। एक हल्के डीबी का चयन एक जोखिम का परिचय देता है कि आपका उपकरण ठीक से स्केल नहीं करेगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.