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

iKonekt كان متعدد المستأجرين من أول ترحيل ليه، مش اتضاف بعدين، وده شكله تباهي بس في الحقيقة اعتراف: إنك تضيفه بعد ما النظام يبقى شغال شبه مستحيل تعمله بشكل مقنع، وكل حد حاول عنده حكاية.

الفصل عايش في قاعدة البيانات. كل جدول من الـ ٢٦ جدول شايل المستأجر اللي بيتبعله، والسياسة اللي بتتأكد من ده بتشتغل مع كل قراءة وكل كتابة، تحت التطبيق خالص. الكويري اللي بينسى الحد مش بيرجع عملاء حد تاني. بيرجع ولا حاجة.

الباج اللي مكانش يقدر يعلن نفسه

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

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

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

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

الفصل بيجيب إيه للشخص العادي

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