متى تكسر قواعد قاعدة البيانات:JSONB والعدّادات

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

أنفقت كلمات كثيرة في الوعظ بالبنية: كل حقيقة في مكان واحد، وكل شيء مرتبط بمراجع، ولا اختصارات. تلك القاعدة، أي انضباط الـ 90% وأكثر الذي شرحته في مقال تطبيع قواعد البيانات، بنت منصة تبقى فيها مئات الجداول متزامنة دون أي بيانات مكررة. يتناول هذا المقال الجانب الآخر: الـ 10%، حيث لا يكون كسر القواعد اختصاراً بل القرار الهندسي الصحيح.

متى تكسر قواعد قاعدة البيانات: القاعدة قبل الاستثناءات

أولاً، الإطار. في منصتي ربما 95% من البيانات علائقية: جداول سليمة، ومراجع سليمة، وبنية سليمة. والاستثناءات هي بالضبط ذلك: استثناءات، ولكل منها سبب مكتوب. هذا الترتيب مهم، لأن الذكاء الاصطناعي سيعرض عليك كسر القواعد باستمرار، و«لأنه أبسط» ليس سبباً أبداً. الخطر ليس في الاستثناء، بل في الاستثناء غير الموثَّق الذي لا يستطيع أحد لاحقاً تمييزه عن الخطأ.

وبعد ذلك، إليك كسور القواعد الثلاثة التي أستخدمها عمداً.

الاستثناء الأول: JSONB للبيانات المرنة فعلاً

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

فكّر في قاعدة بياناتك كخزانة ملفات بأدراج معنونة. JSONB هو الدرج المكتوب عليه «متفرقات»، ودرج المتفرقات مفيد فعلاً، ما دام لا يصبح المكان الذي تحفظ فيه جواز سفرك. المحتوى المشروع: أشياء لا تستطيع معرفة شكلها مسبقاً. إن كان مستخدموك يبنون نماذج مخصصة، فلكل إرسال حقول مختلفة، ولا تستطيع تصميم درج مسبقاً لحقول لم توجد بعد. وينطبق الشيء نفسه على الحقول المخصصة التي يعرّفها المستخدم، وتفضيلات وإعدادات كل مستخدم، والحمولات القادمة من أنظمة شركات أخرى، والبيانات الوصفية السائبة، ولقطات ما قبل/بعد داخل سجلات التدقيق.

القاعدة ذات الجملة الواحدة التي أتبعها:

إن كنت تحتاج إلى ربطها ببيانات أخرى، أو الاستعلام عنها كثيراً، أو فرض علاقات، فاجعلها علائقية. وإن كانت مرنة، أو يعرّفها المستخدم، أو نادراً ما يُستعلم عنها، فلا بأس بـ JSONB.

علامة أن JSONB آمن: البيانات يملكها صف واحد ولا يُستعلم عنها مستقلة عنه. وهذا بالضبط الوضع الذي لا تحدث فيه مشكلات التحديث التي وُجدت البنية لمنعها. وعلامة أنه خطأ: تجد نفسك تريد طرح أسئلة عبر JSONB، مثل «كل المهام الموسومة بعاجل» أو «كل الطلبات لهذا العميل». هذه علاقات، والعلاقات مكانها الجداول.

12 أسبوعاًمسيرتك في الشركات لم تكن الخطة أبداًقدّم طلبك إلى Solopreneur Accelerator.قدّم الآن ←

الاستثناء الثاني: عدّادات لا تستطيع حسابها مباشرة

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

ثم يصل الحجم. مجتمع تحتوي قنواته على 100k منشور لا يستطيع إعادة عدّها عند كل عرض صفحة. وسوق فيه 500k قائمة لا يستطيع إعادة حساب متوسط التقييمات داخل كل نتيجة بحث. ولوحة وظائف تتلقى فيها الشركات 50k طلب لا تستطيع عدّها مباشرة عند كل عرض ملف. عندها تخزّن الرقم، أي عمود عدّاد محسوب مسبقاً، وتصبح قراءته بلا كلفة.

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

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

الاستثناء الثالث: المال دائماً سنتات صحيحة

هذا أقل «كسراً لقاعدة» وأكثر رفضاً لإعداد افتراضي يبدو طبيعياً وهو خطير بصمت. تخزين 12.99 € كالرقم العشري 12.99 يدعو حساب الفاصلة العائمة في الحاسوب إلى أموالك، والرياضيات العائمة تنتج أخطاء تقريب صغيرة مجرد قبيحة في رسم بياني وغير مقبولة في فاتورة.

الحل: خزّن كل مبلغ مالي كعدد صحيح من السنتات. يُخزَّن 12.99 € كـ 1299. الأعداد الصحيحة لا أخطاء تقريب فيها أبداً. ونظام الدفع في Stripe كله يتحدث بهذا العرف، أي المبالغ بأصغر وحدة عملة، فتتطابق قاعدة بياناتك مع مزوّد الدفع أصلاً. والقسمة على 100 تحدث في اللحظة الأخيرة فقط، في طبقة العرض، حيث يكلّف الخطأ عيباً شكلياً لا مالاً.

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

القاعدة العليا: الاستثناءات تُكتب

لاحظ ما تشترك فيه الاستثناءات الثلاثة. لكل منها مُحفِّز ضيق (شكل لا يمكن معرفته؛ كلفة قيست للحساب المباشر؛ طبيعة المال). ولكل منها آلية تعويض (اختبار JOIN؛ مشغّلات المزامنة؛ التحويل في طبقة العرض). وكل منها موثَّق: منصتي تحتفظ بملف قرارات التصميم يسرد كل انحراف مقصود، بالضبط ليتمكن المدققون المستقبليون (بشر أو ذكاء اصطناعي) من التمييز بين الهندسة المتعمدة والإهمال المتراكم.

هذا هو الفرق الحقيقي بين كسر القاعدة المهني والدَّين التقني: أحدهما يأتي بسبب مكتوب، والآخر يأتي بهزّة كتف.

الكتابThe Solopreneur Revolutionلويس غونسالفيس عن بناء مشروع رائد أعمال منفرد بالذكاء الاصطناعي دون ترك وظيفتك.احصل على الكتاب ←

الأسئلة الشائعة

هل JSONB ممارسة سيئة؟

لا، الممارسة السيئة هي سوء استخدام JSONB. فللبيانات المرنة فعلاً التي يملكها صف واحد، هو الأداة الصحيحة ويتجنب تعقيداً بلا فائدة. وطريقة الفشل هي استخدامه للتهرب من تصميم قاعدة البيانات: حشر الوسوم أو المكلَّفين أو العلاقات في كتلة JSON لأن تصميم الجداول المناسبة بدا عملاً شاقاً. طبّق اختبار JOIN فيبقى JSONB أداة لا فخاً.

كيف أعرف متى ينبغي تخزين عدّاد؟

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

لماذا لا أستخدم عموداً عشرياً للمال؟

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

ماذا يحدث إن استخدمت JSONB لكل شيء؟

تحصل على قاعدة بيانات لا تستطيع الإجابة عن الأسئلة. لا علاقات، ولا فرض سلامة، ولا تصفية فعّالة، وتقارير مؤلمة؛ لقد أعدت بناء كومة مستندات بخطوات إضافية. مرونة لم تكن بحاجة إليها، اشتريتها بقابلية الاستعلام التي يقوم عليها عملك. أبقِ البنية لـ 95% واصرف JSONB حيث الشكل مجهول فعلاً.