“خالية من المخطط” تبدو سريعة حتى تبدأ الفرق المختلفة في تخزين نفس المفهوم التجاري بأشكال مختلفة قليلاً. في هذه المرحلة، لم يختفِ المخطط. لقد انتقل فقط إلى كود التطبيق، وسكريبتات الترحيل، وحوادث دعم الإنتاج.
لهذا السبب، تنتهي العديد من الفرق في النهاية بـ Postgres مع `JSONB` كحل وسط: ضمانات علاقات للحقل الأساسي، وتخزين مستندات مرنة للأجزاء التي تتغير دائماً.
## لماذا يعمل JSONB كحل وسط
النمط المفيد ليس "وضع كل شيء في عمود JSON." بل هو فصل الحقول التجارية الثابتة عن البيانات الوصفية المتطورة:
```sql
CREATE TABLE users (
id UUID PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
plan TEXT NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
preferences JSONB NOT NULL DEFAULT '{}'::jsonb
);
CREATE INDEX users_preferences_gin_idx
ON users
USING GIN (preferences);
هذا يمنحك:
- قيود علاقات عادية للحقول المهمة
- استعلامات JSON للتفضيلات المتغيرة أو علامات الميزات
- منصة تشغيلية واحدة بدلاً من نماذج تخزين مجزأة
حيث تشعر الفرق عادةً بالندم على التخزين المستند النقي
يمكن أن تكون قواعد البيانات المستندة لا تزال مناسبة، لكن الألم يظهر غالباً عندما ينمو النظام:
- تصبح الاتساق بين المستندات أكثر صعوبة
- يحتاج التقرير إلى استعلامات علاقات
- تتراكم أشكال الحقول المكررة
- تصبح الترحيلات عملاً إصلاحياً مؤقتاً للبيانات
إذا كان التطبيق يحتوي على تدفقات مالية، حالة الفواتير، الهويات، أو الانضمامات ذات القيمة العالية، عادةً ما يكون Postgres أكثر تماسكًا مع مرور الوقت.
التنازل الصادق
JSONB قوي، لكن من السهل إساءة استخدامه. إذا انتهى بك الأمر إلى دفن كل حقل ذو معنى داخل JSON، ستفقد جزءًا كبيرًا من السبب وراء مساعدة التخزين العلائقي في المقام الأول. استخدمه من أجل المرونة الانتقائية، وليس كعذر لتجنب تصميم المخطط.
MongoDB ليس "خطأ". الخطأ هو الافتراض بأن التخزين الخالي من المخطط أرخص إلى الأبد. غالباً ما يكون أرخص فقط في البداية.
قراءة إضافية