علائقية أو NoSQL؟ خمسة أسئلة من عبدالله بن سنكر قبل اختيار قاعدة البيانات

المطوّر الأول قال «MongoDB أسرع وأرن»، والثاني قال «لا، PostgreSQL هو الأساس»، وأنت كصاحب مشروع ما تدري مين تصدّق، ولا تعرف إن هذا القرار من أصعب القرارات اللي تتغير بعدين. عبدالله بن سنكر ما يبدأ هذا النقاش من أسماء القواعد، يبدأه من أسئلة عن بياناتك أنت. هذا إطاره: خمسة أسئلة تكشف لك الاتجاه قبل ما تسمع أي اسم تقني.

الفرق في فقرة وحدة

القواعد العلائقية مثل PostgreSQL و MySQL تخزّن البيانات في جداول بأعمدة محددة مسبقاً، وتربط الجداول ببعض بعلاقات: العميل في جدول، وطلباته في جدول ثاني يشير له. وتضمن المعاملات (transactions) إن مجموعة عمليات تنجح كلها أو تفشل كلها. أما NoSQL فعائلة واسعة، أشهرها قواعد المستندات مثل MongoDB و Firestore، اللي تخزّن كل سجل كمستند مرن يشبه JSON، وممكن يحمل بداخله البيانات المرتبطة بدل ما يشير لها. وفيه عائلات ثانية مثل قواعد المفتاح والقيمة كـ Redis، وغالباً تُستخدم للتخزين المؤقت والجلسات مو كقاعدة رئيسية.

السؤال الأول: هل بياناتك مترابطة؟

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

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

السؤال الثاني: هل فيه فلوس أو أرصدة؟

تحويل مبلغ من رصيد لرصيد، أو حجز آخر مقعد متاح، أو خصم من المخزون مع إنشاء الطلب في نفس اللحظة. هذي عمليات لازم تتم كلها أو ما يتم شي منها. القواعد العلائقية مبنية من الأساس على هذا الضمان، المعروف بخصائص ACID. وبعض قواعد NoSQL تدعم المعاملات اليوم، لكن بقيود وتفاصيل تختلف من قاعدة لأخرى، فلازم تقرأها بدقة قبل ما تعتمد عليها في شي مالي. تخيّل منتجاً باقي منه قطعة وحدة، وعميلين ضغطوا «اشترِ» في نفس الثانية. بدون معاملة وقفل صحيح، الاثنين يشوفون «متوفر»، والاثنين يدفعون، وأنت تعتذر لواحد منهم.

السؤال الثالث: وش الأسئلة اللي بتسألها لبياناتك؟

هذا السؤال يغفل عنه أغلب الناس، وهو الأهم في قواعد المستندات. القاعدة العلائقية تخليك تسأل أسئلة ما فكرت فيها وقت التصميم: «كم عميلاً من الرياض طلب أكثر من مرتين في رمضان؟» استعلام واحد بلغة SQL. أما قواعد مثل Firestore فتُصمَّم حول الاستعلامات المتوقعة مسبقاً، وبعض الاستعلامات المركّبة تحتاج فهارس تُنشأ لها، والتقارير التحليلية الحرة فيها متعبة. لو مشروعك بيحتاج تقارير ولوحات إدارة متنوعة، احسب هذا من الآن مو بعد سنة. وانتبه لنموذج التسعير كمان: بعض قواعد البيانات السحابية تحاسب على عدد عمليات قراءة المستندات، فشاشة مصممة بشكل سيئ تقرأ آلاف المستندات في كل فتحة ممكن تتحول لفاتورة مفاجئة مع نمو المستخدمين.

السؤالان الرابع والخامس: شكل البيانات وطريقة استخدامها

• هل شكل السجلات يختلف كثيراً من سجل لسجل؟ كتالوج فيه جوالات بمواصفات، وملابس بمقاسات، وكتب بمؤلفين. هنا مرونة المستندات مريحة. ومع ذلك PostgreSQL فيه عمود JSONB يخزّن بيانات مرنة داخل جدول منظّم، فتاخذ الاثنين.
• هل تحتاج تحديثاً لحظياً على الأجهزة بأقل كود خلفي؟ Firestore و Supabase يوفرون الاستماع للتغييرات مباشرة من التطبيق، وهذا يسرّع النموذج الأولي كثيراً.
• هل البيانات ضخمة جداً وبسيطة البنية؟ سجلات أحداث بالملايين، أو قراءات حساسات كل ثانية. هنا قواعد NoSQL المصممة للتوسع الأفقي لها أفضلية حقيقية.
• وش خطة النسخ الاحتياطي والاسترجاع؟ القواعد المُدارة الكبيرة، علائقية أو NoSQL، توفر نسخاً تلقائية، لكن اسأل: هل تقدر ترجع لحالة القاعدة قبل ساعة بالضبط لو أحد حذف بيانات بالغلط؟ وهل جرّبتوا الاسترجاع فعلاً مرة وحدة على الأقل؟
• هل فريقك يعرف SQL؟ لغة عمرها عقود، يعرفها أغلب المطوّرين، وأدواتها ناضجة، ولو تغيّر المطوّر يلقى بديله بسهولة.

الخلاصة العملية

لو ما عندك سبب واضح تختار غيرها، ابدأ بقاعدة علائقية، و PostgreSQL خيار متين لأغلب المشاريع. هذا مو تعصّب، هذا لأن أغلب مشاريع الأعمال بياناتها مترابطة، وفيها فلوس، وتحتاج تقارير. واختر NoSQL لما يكون عندك سبب محدد تقدر تقوله بجملة: بيانات بلا علاقات تقريباً، أو مزامنة لحظية بأقل كود، أو حجم ضخم ببنية بسيطة. وكثير من الأنظمة الناضجة تجمع الاثنين: قاعدة علائقية كمصدر للحقيقة، وقاعدة مفتاح وقيمة للتخزين المؤقت والجلسات.

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