الحد الذي يحفظه قاعدة البيانات، لا الشيفرة

وُلد iKonekt متعدد المستأجرين منذ أول ترحيل له بدلاً من إضافة ذلك لاحقاً، وهو ما يبدو مفاخرة وهو في الحقيقة اعتراف: إضافته لاحقاً تكاد يكون مستحيلاً إقناعياً، وكل من جرّبه لديه قصة.

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

الخطأ الذي لم يستطع أن يُعلن عن نفسه

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

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

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

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

ما يكسبه الفصل الشخص العادي

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