·فريق Kachixbackend-apiserp

حط القواعد في قاعدة البيانات، مش في كل تطبيق بيكلمها

تلات واجهات بتلمس نفس البيانات يعني تلات فرص للاختلاف. القواعد اللي بتحمي الفلوس والثقة مكانها طبقة تحت — وده المكان اللي بنرسم عنده الخط، وليه.

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

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

والحل مش انضباط أكتر. الحل إنك تنقل القاعدة لمكان مفيش عميل يقدر يعديه.

الاختبار: يحصل إيه لو العميل كان غلط؟

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

لو عميل فيه باج، أو نسخة قديمة، أو حد بيحاول يتلاعب، بعت الطلب ده — هل النتيجة هتبقى غلط، مش بس وحشة الشكل؟

لو أيوه، القاعدة بتنزل طبقة تحت، حيث كل المسارات لازم تعدي عليها. تلات حالات من شغلنا بيوضحوا الخط ده عمليًا.

صحة مايتسبقش عليها

في سوق الصنايعية اللي بنيناه، ممكن عميلين يطلبوا نفس الصنايعي لنفس الميعاد في نفس اللحظة. و"اتأكد بعدين اكتب" على مستوى التطبيق بيخسر السباق ده بالتصميم: الاتنين بيقروا ميعاد فاضي، والاتنين بيكتبوا.

فالقاعدة بقت قيد فريد جزئي في Postgres. مستحيل حجزين يكسبوا مع بعض مهما كان كل واحد جه من أنهي تطبيق، لأن قاعدة البيانات نفسها بترفض التاني. والتطبيق لسه بيعرض رسالة لطيفة — بس الضمانة مش معتمدة على إن التطبيق يكون صح.

فلوس ماتزوغش في صمت

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

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

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

ثقة مايتلفش عليها

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

ده بيكلفك إيه

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

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

واقف قدام نفس المشكلة دي في شغلك؟

اتكلم معانا