عبدالله عبدالرحيم بن سنكر يصمّم قاعدة بيانات نظام حجوزات خطوة بخطوة

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

المثال: صالون فيه ثلاثة حلاقين

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

• العملاء (customers): المعرّف، والاسم، ورقم الجوال بصيغة دولية موحدة، وتاريخ الإنشاء.
• الموظفون (staff): المعرّف، والاسم، وحالة النشاط. والموظف اللي ترك العمل يتعطّل ما ينحذف، لأن حجوزاته القديمة تشير له.
• الخدمات (services): الاسم، والمدة بالدقائق، والسعر الحالي، ووقت فاصل بعدها للتجهيز والتنظيف.
• ربط الموظفين بالخدمات (staff_services): مين يقدّم وش. جدول وسيط بسيط، لكنه يمنع حجز صبغة عند حلاق ما يسويها.
• ساعات الدوام (working_hours): الموظف، ويوم الأسبوع، ووقت البداية والنهاية. ويوم فيه فترتين، صباحية ومسائية، يصير صفين.
• الإجازات والاستثناءات (time_off): الموظف، وبداية الفترة ونهايتها، والسبب.
• الحجوزات (bookings): العميل، والموظف، والخدمة، ووقت البداية والنهاية، والحالة، والسعر وقت الحجز، ومصدر الحجز، وتواريخ الإنشاء والإلغاء.

قرارات الوقت: هنا تنزرع أغلب الأخطاء

أول قرار: الوقت يُخزَّن كلحظة مطلقة مع المنطقة الزمنية، في PostgreSQL نوع timestamptz، ويُعرض للمستخدم بتوقيت الرياض. ممكن تقول: «كل عملائي في السعودية، ليش أتعب؟». لأن الخادم نفسه ممكن يكون في منطقة زمنية ثانية، ولأن الفرع الثاني ممكن يفتح في دولة خليجية بتوقيت مختلف، ولأن عميلاً مسافراً يحجز من الخارج. القاعدة بتوقيت موحد، والتحويل عند العرض بس.

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

القلب: منع الحجز المزدوج داخل القاعدة

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

الحل إن القاعدة نفسها ترفض التداخل. في PostgreSQL تستخدم قيد استبعاد (exclusion constraint) على عمود الموظف مع نطاق الوقت من نوع tstzrange وعامل التداخل &&، ويحتاج هذا تفعيل إضافة btree_gist عشان يجمع المساواة على الموظف مع التداخل على الوقت في فهرس واحد. والنطاق الافتراضي نصف مفتوح، يشمل البداية ولا يشمل النهاية، فموعد ينتهي خمسة ونص ما يتعارض مع موعد يبدأ خمسة ونص. وتضيف للقيد شرطاً يخلّيه ينطبق على الحجوزات النشطة فقط، فالحجز الملغي ما يحجز الوقت. بعدها مهما كتب المبرمج في الكود، ومهما تزامن الطلبان، القاعدة تقبل واحداً وترفض الثاني بخطأ واضح يحوّله التطبيق إلى رسالة: «هذا الموعد انحجز للتو، اختر وقتاً ثانياً». ولو كنت على قاعدة ما تدعم هذا النوع من القيود، البديل قفل صف الموظف داخل معاملة (SELECT ... FOR UPDATE) قبل الفحص والحفظ، فما يقدر طلبان يفحصان نفس الحلاق في نفس اللحظة.

حالات الحجز: لا تحذف شيئاً

الحجز يمر بحالات، وكل انتقال بينها له معنى في التقارير. التصميم المعتاد:

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

والحجز الملغي ما ينحذف أبداً. الحذف يمسح تاريخاً تحتاجه: كم نسبة الإلغاء؟ في أي أيام؟ عند أي حلاق؟ تغيير الحالة يحفظ كل هذا، والقيد اللي فوق يتجاهل الملغي تلقائياً.

المواعيد المتاحة: تُحسب، ما تُخزَّن

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

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