0Pricing
Firebase Auth & Realtime Database Apps · درس

استراتيجيات إلغاء التطبيع وتكرار البيانات

صمّم بيانات Realtime Database لقراءات سريعة عبر تكرار البيانات عمدًا، واختيار هياكل غير مطبّعة بدلًا من عمليات الربط، والحفاظ على اتساق النسخ عند الكتابة.

استراتيجيات إلغاء التطبيع وتكرار البيانات درس مجاني في Firebase Auth & Realtime Database Apps على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Firebase Auth & Realtime Database Apps، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Firebase Auth & Realtime Database Apps 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

NoSQL Thinking

Realtime Database has no joins. Instead of normalizing data like a relational schema, you shape data around how you read it. This often means storing the same value in more than one place.

This deliberate redundancy is called denormalization.

The Cost of Joins

In a normalized model, showing a post with its author name would require reading the post, then reading the user node separately for every post. That is many round-trips and slow lists.

Duplicating for Reads

Instead, copy the small bits you display alongside the post. Now one read renders the whole feed item.

{
  "posts": {
    "p1": {
      "text": "Hello",
      "authorId": "u9",
      "authorName": "Alice",
      "authorAvatar": "a9.png"
    }
  }
}

What to Duplicate

Duplicate only the fields you actually display in lists, not entire records.

  • Names, avatars, titles: good candidates
  • Large or sensitive fields: keep them in one place
  • Rarely-changing data: safest to copy

The Consistency Trade-Off

The cost of duplication is keeping copies in sync. If Alice renames herself, every copy of authorName must update. You trade write complexity for read speed.

Multi-Path Updates Keep Copies in Sync

Update all copies atomically with a single multi-path write so no copy is left stale.

import { getDatabase, ref, update } from 'firebase/database';

const updates = {};
updates['/users/u9/name'] = 'Alice B.';
updates['/posts/p1/authorName'] = 'Alice B.';
await update(ref(getDatabase()), updates);

Index Tables

Another denormalization pattern is the index node: a lookup mapping that lets you find related items without scanning. Here we map a user to their post IDs.

{
  "userPosts": {
    "u9": { "p1": true, "p7": true }
  }
}

Avoiding Deep Nesting

Reading a node downloads everything beneath it. Keep your tree shallow so a read does not pull in unrelated children. Split large nested structures into sibling top-level nodes.

When NOT to Denormalize

Denormalization is not always right. Avoid it when:

  • The duplicated field changes very frequently
  • There are many copies to keep consistent
  • The data is large or rarely read together

In those cases, store once and read separately.

Validating Duplicated Data

Use Security Rules .validate to keep duplicated fields trustworthy, for example ensuring an authorName copy is always a non-empty string.

{
  "posts": {
    "$id": {
      "authorName": { ".validate": "newData.isString() && newData.val().length > 0" }
    }
  }
}

Designing for Your Queries

The golden rule: structure data around your most common reads. Write the queries your app needs first, then shape (and duplicate) data so each one is a single, shallow read.

Quick Check

Test your understanding of denormalization.

Recap

You can now model NoSQL data for speed.

  • Denormalize by duplicating displayed fields
  • Keep copies in sync with multi-path updates
  • Use index nodes for relationships
  • Keep the tree shallow to avoid over-fetching
  • Structure data around your common queries

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

هل درس «استراتيجيات إلغاء التطبيع وتكرار البيانات» مجاني؟

نعم — نص درس «استراتيجيات إلغاء التطبيع وتكرار البيانات» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Firebase Auth & Realtime Database Apps، انتقل إلى CoddyKit PRO. تتضمن دورة Firebase Auth & Realtime Database Apps 4 دروس في المجموع.

ماذا ستتعلم في «استراتيجيات إلغاء التطبيع وتكرار البيانات»؟

صمّم بيانات Realtime Database لقراءات سريعة عبر تكرار البيانات عمدًا، واختيار هياكل غير مطبّعة بدلًا من عمليات الربط، والحفاظ على اتساق النسخ عند الكتابة. تتمرن على Firebase Auth & Realtime Database Apps مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Firebase Auth & Realtime Database Apps؟

لا تُشترط خبرة سابقة. Firebase Auth & Realtime Database Apps على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «استراتيجيات إلغاء التطبيع وتكرار البيانات»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Firebase Auth & Realtime Database Apps هذا؟

نعم. كل درس في Firebase Auth & Realtime Database Apps يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. تحديثات Fan-Out للبيانات
  2. عمليات البيانات بالمعاملات
  3. العدادات الذرية وقوائم الانتظار
  4. استراتيجيات إلغاء التطبيع وتكرار البيانات
← العودة إلى Firebase Auth & Realtime Database Apps