لقد استنفدت قرارات الإيجار المتعدد مرتين - مرة في اختيار خاطئ في البداية، ومرة غيرت رأيي في منتصف الطريق من خلال CitizenApp. سواء كانت باهظة الثمن. تشكل بنية قاعدة البيانات التي تختارها عقود API الخاصة بك، ونموذج الأمان الخاص بك، وفي النهاية سقف التوسع الخاص بك. إذا أخطأت في ذلك، فسوف تقوم إما بتسريب البيانات بين العملاء أو نفاد اتصالات قاعدة البيانات لدى 50 عميلاً.
هناك ثلاثة أساليب رئيسية: قاعدة بيانات مشتركة مع أمان على مستوى الصف (RLS)، أو مخططات منفصلة لكل مستأجر، أو قواعد بيانات منفصلة بالكامل. سأشرح لماذا استقريت على قاعدة البيانات المشتركة + RLS + سياق المستأجر على مستوى التطبيق لـ CitizenApp، ومتى تختار بشكل مختلف.
إن جاذبية "قاعدة بيانات واحدة، ومخطط واحد، وعملاء متعددين" واضحة: نشر بسيط، نسخ احتياطية سهلة، ورخيصة الثمن. ولكن يساء فهم RLS. يعتقد الناس أن "مجرد إضافة جملة WHERE" يحل مشكلة الإيجار المتعدد. لا.
التكلفة الحقيقية ليست التنفيذ، بل هي النفقات المعرفية وحجم الانفجار عندما تخطئ. سياسة واحدة تم تكوينها بشكل خاطئ، واستعلام خادع بدون سياق المستأجر، وقد قمت بتسريب بيانات العميل بصمت. أفضّل العزل الصريح في طبقة التطبيق باستخدام RLS باعتباره آلية آمنة من الفشل، وليس الآلية الأساسية.
إليك النموذج العقلي: تطبيقك مسؤول عن سياق المستأجر. RLS الخاصة بـ PostgreSQL هي شبكة الأمان.
إن current_setting('app.tenant_id') هو سياق المستأجر الخاص بك. يمكنك تعيينه لكل طلب في التطبيق الخاص بك: