QuickBooks को कई उपयोगकर्ताओं के लिए Google Drive पर क्यों नहीं रखा जा सकता

विशिष्टताओं में जाने से पहले, यह समझना जरूरी है कि यह एक सामान्य अवधारणा है और हम इसे इस प्रकार संक्षेप में कह सकते हैं कि “client/server या shared database file applications को synced storage (जैसे Google Drive, DropBox, NextCloud, आदि) पर क्यों नहीं रखा जा सकता जब access एक ही उपयोगकर्ता तक सीमित न हो?” QuickBooks एक shared database file mechanism का उपयोग करता है जो 1980 के दशक के applications में आम था, जहाँ एक या कई files को file sharing mechanism के माध्यम से share किया जाता है और application की अलग-अलग copies इस file को modify करने के लिए access करती हैं। Google Drive एक synced storage mechanism है: यानी यह एक स्थान से दूसरे स्थान पर data की copies बनाता है। एक ही file पर एक साथ काम करने वाले लोग एक-दूसरे के changes को overwrite कर सकते हैं और यह अपेक्षा होती है कि इन changes को बाद में manually reconcile किया जाएगा, नजरअंदाज किया जाएगा, या users को नियंत्रित किया जाएगा ताकि वे एक साथ काम न करें।

कुछ प्रकार के multi-user applications के लिए, synced storage का उपयोग किया जा सकता है, लेकिन केवल उन स्थितियों में जहाँ storage system द्वारा application को lock किया जा सकता हो ताकि changes तभी हों जब कोई अन्य उपयोगकर्ता न हो। इसके लिए general purpose file syncing के साथ संभव नहीं होने वाले integration की आवश्यकता होती है। अधिकांश systems जो यह करते हैं, वे database या application layer में बनी syncing mechanism का उपयोग करते हैं, न कि किसी सामान्य उद्देश्य वाली mechanism का जिसे blindly काम करना पड़े। Synced storage के साथ data integrity बनाए रखने के लिए, यह आवश्यक है कि एक समय में केवल एक व्यक्ति file को edit करे, उस file के “save” होने के बाद सभी संभावित users के updates प्राप्त होने की प्रतीक्षा करे, फिर एक अलग user file को edit कर सकता है और यह process दोहरा सकता है। लेकिन एक समय में केवल एक user file पर काम कर सकता है और उसे खुद editing के लिए file खोलने से पहले दूसरे user के updates प्राप्त करने होंगे। अन्यथा system को हर मामले में users से पूछना होगा कि कौन से changes रखने हैं और कौन से हटाने हैं।

यह integrity process किसी database file पर किसी व्यावहारिक तरीके से लागू नहीं की जा सकती। File को हर समय खुला और accessible रहने के लिए design किया गया है, न कि केवल जल्दी से खोलने, edit करने और save करने के लिए। Saving भी manual नहीं होती, और हमेशा अनुमानित नहीं होती। हम आमतौर पर मानते हैं कि उपयोग के दौरान saving लगातार होती रहती है, लेकिन caching उन save operations को भी manually control करना असंभव बना सकती है। लेकिन यह performance कारणों से आवश्यक है।

अक्सर भ्रम तब उत्पन्न होता है क्योंकि एक single user, एक ही समय में किसी अन्य user के system को access करने के डर के बिना, Google Drive या Apple iCloud जैसे synced storage का उपयोग backup mechanism के रूप में कर सकता है (यह बस automatically एक दूरस्थ copy बनाता है) और/या file को replicate करने के साधन के रूप में ताकि single user इसे पहले एक स्थान से और फिर दूसरे स्थान से उपयोग कर सके, बिना file को manually एक स्थान से दूसरे स्थान पर move किए। जब तक वह single user स्थानों के बीच move करते समय यह सुनिश्चित करने के लिए पर्याप्त समय लेता है कि कोई भी cache flush हो गई है और syncs और locks पूरे हो गए हैं, या यह सुनिश्चित करता है कि उसने application का पहला instance खुला नहीं छोड़ा है, वह उचित रूप से एक सुरक्षित system मान सकता है (लेकिन इसकी पूरी गारंटी नहीं दे सकता - mechanism में तब भी race conditions का बहुत कम जोखिम होता है।) क्योंकि single user mode में application के साथ synced storage का उपयोग “एक तरीका” है, कई non-technical accounting या financial workers गलत तरीके से यह मान लेंगे कि multi-user simultaneous access, जो पूरी तरह अलग है, भी काम करेगा। हालाँकि, यह संभव नहीं है।

होता यह है कि multiple users के बीच race condition हो जाती है और आप कभी पूरी तरह सुनिश्चित नहीं हो सकते कि यह नहीं हुई है। कभी-कभी data बस खराब हो जाएगा और इसमें कोई संदेह नहीं कि race condition हुई है क्योंकि numbers बेहद गलत होंगी। लेकिन अधिकतर, कुछ transactions बस खो जाएंगी भले ही उन्हें review किया जा चुका हो।

एक उदाहरण लेते हैं। User 1 घर पर है और QuickBooks में एक नई receipt enter करता है। यह change local computer पर save होना शुरू होता है और उसके पूरा होने के बाद, यह नई file को Google Drive पर cloud में forward करना शुरू करता है। User 2 office में है और इस दौरान एक invoice पर customer payment enter करना शुरू करता है। User 2 की QuickBooks datafile की copy खुली है और उपयोग में रहने के दौरान overwrite नहीं की जा सकती, इसलिए Google Drive को भेजी जा रही copy User 2 तक नहीं पहुँच सकती। एक बार जब User 2 अपना change save करता है, तो उसकी copy भी Google Drive पर भेजना चाहती है। Google Drive के पास अब दो documents हैं जो शुरू में एक जैसे थे लेकिन अब उनमें दो बिल्कुल अलग changes हैं, और किसी भी copy में दोनों नहीं हैं। इन्हें merge करने का कोई तरीका नहीं है, इसलिए यह या तो User 1 को master मान सकता है और User 2 के changes हटा सकता है (जैसे पहली प्राथमिकता)। या यह User 2 के changes accept कर सकता है और User 1 के changes हटा सकता है (जैसे नवीनतम प्राथमिकता)। या, निश्चित रूप से, यह सभी changes हटा सकता है और कोई भी accept नहीं कर सकता। किसी भी मामले में, सभी users के financial transactions को retain नहीं किया जाता, भले ही उन्होंने उन्हें locally save किया हो। या तो User 1 या User 2 (या संभवतः दोनों) के पास ऐसा data होगा जिसे उन्होंने save होने के बाद अचानक गायब हो जाते देखा। अधिक users जोड़ें, और समस्या बढ़ती जाती है।

समस्या का एक हिस्सा यह है कि file access level पर काम करते समय, और पूरे file level पर data sync और share करते समय, केवल एक record या row को lock करने, transactions को अलग रखने या changes को merge करने का कोई तरीका नहीं है। File एक single entity है और यह बदल गई है। यह सब कुछ या कुछ नहीं है। Individual QuickBooks applications एक-दूसरे से सीधे, या database file के माध्यम से, इस समस्या को हल करने के लिए writes, saves, reads, आदि coordinate करने के लिए बात नहीं कर सकते। वे अंधे हैं और यह नहीं जान सकते कि एक ही समय में अन्य applications भी file के साथ काम करने की कोशिश कर रहे हैं क्योंकि प्रत्येक के पास file की अपनी unique copy है, उनके बीच communications की अनुमति देने के लिए कुछ भी “shared” नहीं है। Copies एक-दूसरे से बंधी नहीं हैं, इसमें कोई quantum state नहीं है। और फिर हम slow या buggy Internet connection होने पर, या इससे भी बुरा, जब एक instance offline हो तो एक या अधिक application instances का उपयोग करने की संभावित समस्याओं को जोड़ सकते हैं। Synchronization अंततः होने पर घंटों या दिनों के changes को overwrite करना पड़ सकता है, या overwrite हो सकते हैं। हम शायद ही milliseconds की बात करते हैं, अक्सर data के दिनों की।

जब locally shared files द्वारा यह समस्या handle की जाती है, तो यह बहुआयामी होती है। पहले, केवल एक file होती है, उस file की copies नहीं। इसलिए सभी changes सभी copies को एक साथ और तुरंत उपलब्ध होते हैं। जब application का एक instance file में data write करने वाला होता है तो वह एक locking और alerting mechanism का उपयोग करता है, जैसे Clustered File Systems SANs को काम करने की अनुमति देते हैं, जहाँ वह अन्य application instances को signal कर सकता है कि एक change किया जा रहा है और उन्हें उसके पूरा होने का इंतजार करना होगा, और फिर जारी रखने से पहले data की अपनी copy refresh करनी होगी। केवल एक instance write कर सकता है और बाकी सभी को इंतजार करना होगा। कोई race conditions नहीं हैं क्योंकि lock शुरू करने से पहले प्राप्त किया जाता है, और पूरा होने पर release किया जाता है। और सभी instances तभी काम करते हैं जब data currently accessible हो, connection खो जाने पर वे आगे बढ़ने में असमर्थ हैं। यह एक critical data integrity protection mechanism है। कुछ applications इस mechanism को और भी आगे ले जाएंगे और shared file के माध्यम से नहीं बल्कि direct communications channels जोड़ेंगे ताकि यह process बेहतर performance के लिए तेज हो। लेकिन बहुत कम इतना आगे जाएंगे क्योंकि एक बार जब आप उस level पर जाते हैं तो generally इतना आसान होता है कि बस एक modern application पर switch कर लें बजाय decades पुराने designs पर modern multi-user systems को fit करने की कोशिश के।

उम्मीद है कि इससे यह स्पष्ट हो गया होगा कि accountants क्यों आमतौर पर सोच सकते हैं कि sync’d files काम करेंगी और वे अक्सर यह क्यों दावा करते हैं कि यह “मेरे लिए काम किया” जब उन्हें कहना चाहिए “मुझे किस्मत मिली” या “मैंने इसे एक बिल्कुल अलग scenario में उपयोग किया जो multi-user environment पर लागू नहीं होता” और इसीलिए आप Google Drive, NextCloud, iCloud, DropBox और अन्य का उपयोग QuickBooks और अन्य legacy style applications के साथ backups और data transfers के लिए बिल्कुल कर सकते हैं, लेकिन इसे multi-user access प्राप्त करने के साधन के रूप में उपयोग करने की कोशिश नहीं कर सकते क्योंकि यह data को intact नहीं रख सकता।