تأسیس ۲۰۰۸ · نسخهٔ دیجیتال · 19 ژوئن 2026

SMB IT Journal

منبع فناوری اطلاعات برای کسب‌وکارهای کوچک

فارسی

چرا QuickBooks نمی‌تواند برای چند کاربر روی Google Drive ذخیره شود

پیش از آنکه وارد جزئیات شویم، مهم است بدانیم که این یک مفهوم کلی است و می‌توان آن را به این صورت خلاصه کرد: «چرا برنامه‌های مبتنی بر پایگاه‌داده مشترک یا کلاینت/سرور نمی‌توانند روی فضای ذخیره‌سازی همگام‌سازی‌شده (مانند Google Drive، DropBox، NextCloud و غیره) ذخیره شوند وقتی دسترسی به یک کاربر واحد محدود نشده است؟» QuickBooks از مکانیزم فایل پایگاه‌داده مشترکی استفاده می‌کند که در برنامه‌های سبک دهه ۱۹۸۰ رایج است؛ جایی که یک فایل یا مجموعه‌ای از فایل‌ها از طریق مکانیزم اشتراک‌گذاری فایل به اشتراک گذاشته می‌شود و نسخه‌های جداگانه برنامه هر کدام به این فایل دسترسی دارند تا آن را ویرایش کنند. Google Drive یک مکانیزم ذخیره‌سازی همگام‌سازی‌شده است: یعنی کپی‌هایی از داده‌ها را از یک مکان به مکان دیگر منتقل می‌کند. کاربرانی که همزمان روی یک فایل کار می‌کنند می‌توانند – و اغلب چنین می‌کنند – تغییرات یکدیگر را بازنویسی کنند و انتظار می‌رود این تغییرات بعداً به صورت دستی آشتی داده شوند، نادیده گرفته شوند، یا کاربران کنترل شوند تا همزمان کار نکنند.

برای برخی انواع برنامه‌های چند کاربره، ذخیره‌سازی همگام‌سازی‌شده قابل استفاده است، اما تنها در مواردی که برنامه قادر باشد توسط سیستم ذخیره‌سازی قفل شود تا فقط زمانی که کاربران دیگری حضور ندارند، تغییرات را مجاز بداند. این نیازمند سطحی از یکپارچگی است که با همگام‌سازی فایل‌های عمومی عملی نیست. اکثر سیستم‌هایی که این کار را انجام می‌دهند از مکانیزم همگام‌سازی که درون لایه پایگاه‌داده یا برنامه ساخته شده استفاده می‌کنند، نه یک مکانیزم عمومی که باید به صورت کور عمل کند. برای حفظ یکپارچگی داده‌ها با ذخیره‌سازی همگام‌سازی‌شده، لازم است تنها یک نفر در هر زمان فایلی را ویرایش کند، صبر کند تا همه کاربران احتمالی به‌روزرسانی‌های انجام‌شده پس از «ذخیره» آن فایل را دریافت کنند، سپس کاربر دیگری می‌تواند آن فایل را ویرایش کند و این فرآیند را تکرار کند. اما تنها یک کاربر در هر زمان می‌تواند روی فایل کار کند و باید به‌روزرسانی‌های کاربر دیگر را دریافت کند قبل از اینکه فایل را برای ویرایش باز کند. وگرنه سیستم باید از کاربران بخواهد در هر مورد مشخص کنند کدام تغییرات را نگه دارند و کدام را حذف کنند.

این فرآیند یکپارچگی نمی‌تواند به هیچ روش واقع‌بینانه‌ای روی یک فایل پایگاه‌داده اعمال شود. فایل طراحی شده است که همیشه باز و قابل دسترس باشد، نه فقط برای باز کردن، ویرایش و ذخیره سریع. ذخیره‌سازی نیز دستی نیست و همیشه قابل پیش‌بینی نیست. معمولاً فرض می‌کنیم که ذخیره‌سازی در طول استفاده به صورت پیوسته اتفاق می‌افتد، اما کشینگ می‌تواند حتی آن عملیات ذخیره را برای کنترل دستی غیرممکن کند. این اما به دلایل عملکردی ضروری است.

سردرگمی اغلب از اینجا ناشی می‌شود که یک کاربر منفرد، بدون نگرانی از دسترسی همزمان کاربر دیگری، می‌تواند از ذخیره‌سازی همگام‌سازی‌شده مانند Google Drive یا Apple iCloud به عنوان یک مکانیزم پشتیبان‌گیری (که به سادگی یک نسخه از راه دور را به صورت خودکار ایجاد می‌کند) و/یا به عنوان روشی برای تکثیر فایل استفاده کند تا کاربر منفرد بتواند ابتدا از یک مکان و سپس از مکان دیگری از آن استفاده کند بدون نیاز به انتقال دستی فایل. تا زمانی که آن کاربر منفرد زمان کافی برای جابجایی بین مکان‌ها فراهم کند تا اطمینان حاصل شود هر حافظه پنهانی تخلیه شده و همگام‌سازی‌ها و قفل‌ها کامل شده‌اند، یا اطمینان حاصل کند که نسخه اول برنامه را باز نگذاشته، می‌تواند به طور معقول یک سیستم امن فرض کند (اما نمی‌تواند کاملاً تضمین کند – این مکانیزم حتی در این صورت خطر ناچیزی از شرایط رقابتی دارد). چون «راهی» برای استفاده ایمن از ذخیره‌سازی همگام‌سازی‌شده با برنامه در حالت تک‌کاربره وجود دارد، بسیاری از کارمندان حسابداری یا مالی غیرفنی به اشتباه فرض می‌کنند که دسترسی همزمان چندکاربره، که کاملاً متفاوت است، هم کار می‌کند. این اما ممکن نیست.

آنچه رخ می‌دهد این است که یک شرایط رقابتی بین کاربران متعدد دارید و هرگز نمی‌توانید کاملاً مطمئن باشید که چنین اتفاقی نیفتاده. گاهی داده‌ها به سادگی خراب خواهند بود و بدون تردید شرایط رقابتی رخ داده زیرا اعداد به شدت نادرست خواهند بود. اما بیشتر اوقات، برخی تراکنش‌ها به سادگی از دست خواهند رفت حتی پس از اینکه مرور شده‌اند.

بگذارید مثالی بزنیم. کاربر ۱ در خانه است و یک رسید جدید را در QuickBooks وارد می‌کند. این تغییر شروع به ذخیره در کامپیوتر محلی می‌کند و پس از اتمام آن، شروع به ارسال فایل جدید به Google Drive در فضای ابری (آنلاین) می‌کند. کاربر ۲ در دفتر است و در این زمان شروع به وارد کردن پرداخت یک مشتری برای یک فاکتور می‌کند. نسخه QuickBooks کاربر ۲ باز است و در حالت استفاده نمی‌تواند بازنویسی شود، پس نسخه‌ای که به Google Drive ارسال می‌شود نمی‌تواند به کاربر ۲ برسد. وقتی کاربر ۲ تغییرش را ذخیره می‌کند، نسخه او هم می‌خواهد به Google Drive ارسال شود. Google Drive حالا باید با دو سند که از یک نقطه شروع کرده‌اند اما حالا دو تغییر کاملاً متفاوت دارند کاری انجام دهد، در حالی که هیچ کدام هر دو تغییر را ندارند. هیچ راه ممکنی برای ادغام آن‌ها ندارد، پس یا می‌تواند کاربر ۱ را به عنوان نسخه اصلی بپذیرد و تغییرات کاربر ۲ را رد کند (مثلاً اولویت اول). یا می‌تواند تغییرات کاربر ۲ را بپذیرد و تغییرات کاربر ۱ را رد کند (مثلاً اولویت آخرین). یا البته می‌تواند همه تغییرات را رد کند و هیچ کدام را نپذیرد. در هیچ حالتی تراکنش‌های مالی همه کاربران حفظ نمی‌شود حتی پس از اینکه آن‌ها را به صورت محلی ذخیره کرده‌اند. یا کاربر ۱ یا کاربر ۲ (یا احتمالاً هر دو) داده‌هایی خواهند داشت که اعتقاد داشتند ذخیره شده ناگهان ناپدید می‌شوند. با افزودن کاربران بیشتر، مشکل بزرگ‌تر می‌شود.

بخشی از مشکل این است که وقتی در سطح دسترسی فایل کار می‌کنیم و داده‌ها را در سطح فایل کامل همگام‌سازی و به اشتراک می‌گذاریم، هیچ راهی برای قفل کردن فقط یک رکورد یا ردیف، یا نگه داشتن تراکنش‌ها جدا از هم یا ادغام تغییرات وجود ندارد. فایل یک موجودیت واحد است و تغییر کرده. همه یا هیچ. برنامه‌های QuickBooks جداگانه نمی‌توانند مستقیماً با یکدیگر یا از طریق فایل پایگاه‌داده ارتباط برقرار کنند تا نوشتن‌ها، ذخیره‌سازی‌ها، خواندن‌ها و غیره را هماهنگ کنند تا این مشکل را حل کنند. آن‌ها کور هستند و نمی‌توانند بدانند که برنامه‌های دیگری همزمان سعی می‌کنند با فایل کار کنند چون هر کدام نسخه منحصربه‌فرد خود از فایل را دارند، هیچ چیز «مشترکی» بین آن‌ها برای ارتباط وجود ندارد. نسخه‌ها به هم متصل نیستند، هیچ حالت کوانتومی در اینجا وجود ندارد. و سپس می‌توانیم مشکلات احتمالی ناشی از استفاده از یک یا چند نمونه برنامه در هنگام اتصال اینترنتی کند یا معیوب، یا بدتر، زمانی که یک نمونه آفلاین است را اضافه کنیم. ممکن است ساعت‌ها یا روزها تغییرات وجود داشته باشد که باید بازنویسی شوند یا بازنویسی کنند، زمانی که همگام‌سازی سرانجام اتفاق می‌افتد. ما به ندرت از میلی‌ثانیه صحبت می‌کنیم، بلکه اغلب از روزها داده صحبت می‌کنیم.

نحوه مدیریت این مشکل، وقتی مدیریت می‌شود، توسط فایل‌های به اشتراک گذاشته شده به صورت محلی چند وجهی است. اول، تنها یک فایل وجود دارد، نه کپی‌های آن فایل. بنابراین همه تغییرات به صورت همزمان و فوری برای همه نسخه‌های برنامه در دسترس هستند. وقتی یک نمونه از برنامه قرار است داده‌ها را به فایل بنویسد از یک مکانیزم قفل‌گذاری و هشداردهی مشابه نحوه کار سیستم‌های فایل کلاستر‌شده با SANها استفاده می‌کند، جایی که می‌تواند به نمونه‌های دیگر برنامه سیگنال دهد که تغییری در حال انجام است و آن‌ها باید صبر کنند تا کامل شود، و سپس نسخه خود از داده‌ها را قبل از ادامه تازه کنند. تنها یک نمونه می‌تواند بنویسد و همه دیگران باید صبر کنند. هیچ شرایط رقابتی وجود ندارد چون قفل قبل از شروع به دست می‌آید و بعد از اتمام آزاد می‌شود. و همه نمونه‌ها تنها تا زمانی که داده‌ها در حال حاضر قابل دسترس هستند کار می‌کنند؛ اگر اتصال قطع شود آن‌ها نمی‌توانند ادامه دهند. یک مکانیزم حفاظت از یکپارچگی داده‌های حیاتی. برخی برنامه‌ها این مکانیزم را به سطح بالاتری می‌برند و کانال‌های ارتباطی مستقیم (نه از طریق فایل مشترک) اضافه می‌کنند تا این فرآیند را برای عملکرد بهتر سریع‌تر کنند. اما کمتر کسی تا این حد پیش می‌رود زیرا وقتی به آن سطح می‌رسید، معمولاً بسیار آسان‌تر است که به سادگی به یک برنامه مدرن منتقل شوید تا اینکه سعی کنید سیستم‌های چندکاربره مدرن را روی طراحی‌های دهه‌ها قدیمی جاسازی کنید.

امیدواریم این توضیح روشن کرده باشد چرا حسابداران اغلب فکر می‌کنند فایل‌های همگام‌سازی‌شده کار خواهند کرد و چرا اغلب ادعا می‌کنند که «برای من کار کرد» در حالی که باید می‌گفتند «شانس آوردم» یا «از آن در یک سناریوی کاملاً متفاوت استفاده کردم که برای محیط چندکاربره قابل اعمال نیست» و چرا می‌توانید کاملاً از Google Drive، NextCloud، iCloud، DropBox و موارد دیگر با QuickBooks و سایر برنامه‌های سبک قدیمی برای پشتیبان‌گیری و انتقال داده استفاده کنید اما نمی‌توان آن را به عنوان روشی برای دسترسی چندکاربره در نظر گرفت زیرا به سادگی نمی‌تواند داده‌ها را دست نخورده نگه دارد.

آگهی

SMB IT Journal — the IT resource for small business