لماذا لا يمكن تخزين QuickBooks على Google Drive لمستخدمين متعددين

قبل أن نتعمق في التفاصيل، من المهم أن نفهم أن هذا مفهوم عام ويمكننا في الواقع تلخيصه في: “لماذا لا يمكن تخزين تطبيقات العميل/الخادم أو تطبيقات قواعد البيانات المشتركة على وحدات تخزين متزامنة (مثل Google Drive وDropBox وNextCloud وما إلى ذلك) عندما لا يكون الوصول مقيدًا بمستخدم واحد؟” تستخدم QuickBooks آلية ملفات قاعدة بيانات مشتركة شائعة في تطبيقات الثمانينيات حيث يتم مشاركة ملف واحد أو مجموعة من الملفات عبر آلية مشاركة الملفات وتصل نسخ التطبيق الفردية إلى هذا الملف لتعديله. Google Drive هي آلية تخزين متزامنة: مما يعني أنها تنشئ نسخًا من البيانات من موقع إلى آخر. يمكن للمستخدمين الذين يعملون على نفس الملف في نفس الوقت، وغالبًا ما يحدث ذلك، أن يتجاوز كل منهم تغييرات الآخر، والتوقع هو أن يتم التوفيق بين هذه التغييرات يدويًا لاحقًا، أو تجاهلها، أو أن يُتحكم في المستخدمين لمنعهم من العمل في نفس الوقت.

بالنسبة لبعض أنواع تطبيقات المستخدمين المتعددين، يمكن الاستفادة من التخزين المتزامن ولكن فقط في الحالات التي يكون فيها التطبيق قادرًا على أن يقفل بواسطة نظام التخزين للسماح بالتغييرات فقط عندما لا يوجد مستخدمون آخرون. وهذا يتطلب مستوى من التكامل غير عملي مع مزامنة الملفات للأغراض العامة. تستخدم معظم الأنظمة التي تفعل ذلك آلية مزامنة مدمجة إما في طبقة قاعدة البيانات أو التطبيق، وليس آلية للأغراض العامة يجب أن تعمل بشكل أعمى. من أجل الحفاظ على سلامة البيانات مع التخزين المتزامن، من الضروري أن يقوم شخص واحد فقط بتحرير الملف في كل مرة، وانتظار جميع المستخدمين المحتملين لاستلام التحديثات التي أُجريت بعد “حفظ” ذلك الملف، ثم يمكن لمستخدم مختلف تحرير الملف وتكرار العملية. ولكن لا يمكن لسوى مستخدم واحد في كل مرة العمل على الملف ويجب أن يستلم تحديثات المستخدم الآخر قبل فتح الملف للتحرير. وإلا يجب على النظام أن يسأل المستخدمين عن التغييرات التي يجب الاحتفاظ بها وأيها يجب تجاهلها في كل حالة.

لا يمكن تطبيق عملية التحقق من السلامة هذه على ملف قاعدة بيانات بأي طريقة واقعية. الملف مصمم ليكون مفتوحًا ويمكن الوصول إليه طوال الوقت، وليس فقط للفتح السريع والتحرير والحفظ. الحفظ أيضًا ليس يدويًا، وليس دائمًا قابلًا للتنبؤ. نفترض عمومًا أن الحفظ يحدث بشكل مستمر أثناء الاستخدام، لكن التخزين المؤقت (الكاش) يمكن أن يجعل حتى تلك العمليات مستحيلة التحكم اليدوي فيها. لكن هذا ضروري لأسباب الأداء.

كثيرًا ما ينشأ الالتباس لأن مستخدمًا واحدًا، دون الخوف من مستخدم آخر يصل إلى النظام في نفس الوقت، يمكنه استخدام التخزين المتزامن، مثل Google Drive أو Apple iCloud، كآلية نسخ احتياطي (فهو ببساطة ينشئ نسخة بعيدة تلقائيًا) و/أو كوسيلة لنسخ الملف بحيث يمكن للمستخدم الواحد استخدامه أولًا من موقع ثم من موقع آخر دون الحاجة إلى نقل الملف يدويًا من موقع إلى موقع. طالما أن ذلك المستخدم الواحد يأخذ وقتًا كافيًا عند الانتقال بين المواقع لضمان مسح أي تخزين مؤقت وإتمام عمليات المزامنة والقفل، أو يضمن أنه لم يترك النسخة الأولى من التطبيق مفتوحة، يمكنه افتراض نظام آمن بشكل معقول (لكنه لا يستطيع ضمان ذلك تمامًا - فالآلية تحمل خطرًا ضئيلًا من ظروف السباق حتى في هذه الحالة.) لأن هناك “طريقة” لاستخدام التخزين المتزامن بأمان مع التطبيق في وضع المستخدم الواحد، كثيرًا ما يفترض العاملون في المحاسبة أو الشؤون المالية غير التقنيين بشكل خاطئ أن الوصول المتزامن لمستخدمين متعددين، الذي يختلف اختلافًا جوهريًا، سيعمل أيضًا. غير أن ذلك غير ممكن.

ما يحدث هو أن لديك حالة سباق بين مستخدمين متعددين ولا يمكنك أبدًا التأكد تمامًا من أن ذلك لم يحدث. أحيانًا ستكون البيانات ببساطة خاطئة ولا يوجد شك في أن حالة سباق قد حدثت إذ ستكون الأرقام غير دقيقة بشكل صارخ. لكن في أغلب الأحيان، ستُفقد بعض المعاملات ببساطة حتى بعد مراجعتها.

لنأخذ مثالًا. المستخدم 1 في المنزل ويُدخل إيصالًا جديدًا في QuickBooks. يبدأ هذا التغيير في الحفظ على الكمبيوتر المحلي وبعد اكتمال ذلك، يبدأ في إرسال الملف الجديد إلى Google Drive في السحابة (الإنترنت). المستخدم 2 في المكتب ويبدأ في إدخال دفعة عميل على فاتورة خلال هذا الوقت. نسخة المستخدم 2 من ملف بيانات QuickBooks مفتوحة ولا يمكن الكتابة فوقها أثناء الاستخدام، لذا لا يمكن للنسخة المُرسلة إلى Google Drive الوصول إلى المستخدم 2. بمجرد أن يحفظ المستخدم 2 تغييره، تريد نسخته أيضًا الإرسال إلى Google Drive. يجب على Google Drive الآن أن يتعامل مع وثيقتين بدأتا متطابقتين لكن لديهما الآن تغييرات مختلفة جذريًا، لكن لا تحتوي أي نسخة على كليهما. ليس لديه أي وسيلة ممكنة لدمجهما، لذا يمكنه إما قبول المستخدم 1 كملف رئيسي وتجاهل تغييرات المستخدم 2 (مثلًا: أولوية الأول). أو يمكنه قبول تغييرات المستخدم 2 وتجاهل تغييرات المستخدم 1 (مثلًا: أولوية الأحدث). أو بالطبع يمكنه تجاهل جميع التغييرات وعدم قبول أي منها. في أي حال، لا تُحتفظ بجميع المعاملات المالية لكلا المستخدمين حتى بعد حفظها محليًا. إما المستخدم 1 أو المستخدم 2 (أو ربما كلاهما) سيجد أن البيانات التي اعتقد أنها محفوظة قد اختفت فجأة. أضف المزيد من المستخدمين، وتكبر المشكلة فقط.

جزء من المشكلة هو أنه عند العمل على مستوى الوصول إلى الملفات، ومزامنة البيانات ومشاركتها على مستوى الملف الكامل، لا توجد طريقة لقفل سجل أو صف واحد فقط، أو لإبقاء المعاملات منفصلة أو دمج التغييرات. الملف كيان واحد وقد تغير. إما الكل أو لا شيء. لا يمكن لتطبيقات QuickBooks الفردية التواصل مع بعضها مباشرة، ولا من خلال ملف قاعدة البيانات، لتنسيق عمليات الكتابة والحفظ والقراءة وما إلى ذلك للتغلب على هذه المشكلة. إنها عمياء ولا تستطيع معرفة أن تطبيقات أخرى تحاول العمل مع الملف في نفس الوقت لأن كل تطبيق لديه نسخته الفريدة الخاصة من الملف، ولا يوجد شيء “مشترك” بينها للسماح بالاتصالات. النسخ غير مرتبطة ببعضها، لا توجد حالة كمومية هنا. ثم يمكننا إضافة المشاكل المحتملة مع نسخة أو أكثر من نسخ التطبيق المستخدمة عند وجود اتصال إنترنت بطيء أو معطوب أو ما هو أسوأ، عندما تكون نسخة غير متصلة بالإنترنت. يمكن أن تكون هناك ساعات أو أيام من التغييرات يجب الكتابة فوقها، أو الكتابة فوقها، عندما تحدث المزامنة أخيرًا. نادرًا ما نتحدث عن ميلي ثانية، بل في أغلب الأحيان عن أيام من البيانات.

كيفية التعامل مع هذه المشكلة، عند التعامل معها، بواسطة الملفات المشتركة محليًا متعددة الجوانب. أولًا، يوجد ملف واحد فقط، وليس نسخًا من ذلك الملف. لذا جميع التغييرات متاحة لجميع نسخ التطبيق في نفس الوقت وفورًا. عندما تريد إحدى نسخ التطبيق كتابة بيانات في الملف، تستخدم آلية قفل وتنبيه مشابهة لكيفية سماح أنظمة الملفات المُجمَّعة لشبكات SAN بالعمل، حيث يمكنها إشارة نسخ التطبيق الأخرى بأن تغييرًا يتم إجراؤه وأنه يجب عليها الانتظار حتى يكتمل، ثم تحديث نسختها من البيانات قبل المتابعة. نسخة واحدة فقط يمكنها الكتابة ويجب على جميع الأخريات الانتظار. لا توجد حالات سباق لأن القفل يُحصل عليه قبل البدء، ويُفرج عنه عند الانتهاء. وجميع النسخ تعمل فقط طالما البيانات متاحة حاليًا، وإذا فُقد الاتصال فلن تتمكن من المتابعة. آلية حماية بالغة الأهمية لسلامة البيانات. بعض التطبيقات ستأخذ هذه الآلية إلى مستوى أعلى وتضيف قنوات اتصال مباشرة (بدلًا من خلال الملف المشترك) لجعل هذه العملية أسرع لأداء أفضل. لكن القليل سيذهب إلى هذا الحد لأنه بمجرد وصولك إلى هذا المستوى يكون من الأسهل عمومًا الانتقال إلى تطبيق حديث بدلًا من محاولة إقحام أنظمة متعددة المستخدمين الحديثة على تصميمات عمرها عقود.

نأمل أن يكون هذا قد أوضح سبب اعتقاد المحاسبين عادةً أن الملفات المتزامنة ستعمل ولماذا كثيرًا ما يدّعون أنها “نجحت معي” في حين يجب أن يقولوا “كنت محظوظًا” أو “استخدمتها في سيناريو مختلف تمامًا لا ينطبق على بيئة متعددة المستخدمين”، ولماذا يمكنك تمامًا استخدام Google Drive وNextCloud وiCloud وDropBox وغيرها مع QuickBooks وتطبيقات الأسلوب القديم الأخرى للنسخ الاحتياطية ونقل البيانات، لكن لا يمكن محاولة استخدامها كوسيلة للحصول على وصول متعدد المستخدمين لأنها ببساطة لا تستطيع الحفاظ على سلامة البيانات.