0Pricing
PostgreSQL Performance & Query Optimization · درس

تصميم المفاتيح الأساسية والمفاتيح البديلة

تعلّم كيف يؤثر الاختيار بين المفاتيح الطبيعية والمفاتيح البديلة المتسلسلة وUUIDs في حجم الفهرس ومعدل الإدراج والأداء العام للاستعلامات

تصميم المفاتيح الأساسية والمفاتيح البديلة درس مجاني في PostgreSQL Performance & Query Optimization على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في PostgreSQL Performance & Query Optimization، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة PostgreSQL Performance & Query Optimization 4 دروس في المجموع.

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

Natural vs Surrogate Keys

A natural key is a real-world attribute (e.g. email). A surrogate key is a meaningless generated value (e.g. an integer id). Surrogate keys stay stable even when business data changes.

Why Key Choice Affects Performance

The primary key is referenced by every foreign key and many indexes. A wide key bloats all of those structures, increasing disk usage and cache pressure. Narrow keys keep indexes small and fast.

Sequential Integer Keys

The classic choice is a monotonically increasing integer. New rows append to the end of the B-tree, minimizing page splits and keeping inserts fast.

CREATE TABLE orders (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  total NUMERIC
);

IDENTITY vs serial

Prefer the SQL-standard GENERATED ALWAYS AS IDENTITY over the older serial pseudo-type. It is cleaner and avoids ownership quirks with the underlying sequence.

The UUID Temptation

UUIDs are great for distributed systems because clients can generate them. But random UUIDs (v4) scatter inserts all over the index, causing page splits and poor cache locality.

CREATE TABLE events (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  payload JSONB
);

Time-Ordered UUIDs

If you need UUIDs, prefer a time-ordered variant (UUIDv7) so values increase roughly with time. This restores the append-friendly behavior of sequential keys while keeping global uniqueness.

Key Width Matters

A BIGINT is 8 bytes; a UUID is 16 bytes. Every secondary index stores the primary key, so wider keys multiply storage across all of them. Measure the impact.

SELECT pg_size_pretty(pg_relation_size('orders_pkey'));

Composite Primary Keys

Sometimes the natural key spans two columns, such as (order_id, line_no) in a detail table. Keep composite keys narrow and put the most selective column first.

CREATE TABLE order_lines (
  order_id BIGINT,
  line_no  INT,
  PRIMARY KEY (order_id, line_no)
);

Foreign Keys Inherit the Cost

Every child row stores a copy of the parent key. A 16-byte UUID parent key makes a million-row child table 8 MB larger than an 8-byte integer would. Multiply by every referencing table.

Choosing in Practice

Guidelines:

  • Default to BIGINT IDENTITY for single-database apps
  • Use time-ordered UUIDs when clients must generate ids or you shard
  • Avoid random v4 UUIDs as primary keys on hot insert paths
  • Keep composite natural keys short

Indexing the Foreign Key Side

Whatever key you pick, always index the child's foreign key column. Without it, deleting or updating a parent forces a full scan of the child table to check references.

CREATE INDEX idx_order_lines_order
ON order_lines (order_id);

Quick Check

Test your key-design knowledge.

Recap

You learned key design for performance:

  • Surrogate keys stay stable; natural keys can change
  • Narrow keys shrink every index and foreign key
  • Sequential BIGINT IDENTITY inserts are cheap
  • Random v4 UUIDs scatter inserts; prefer time-ordered UUIDs
  • Keep composite keys short and selective-first

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

هل درس «تصميم المفاتيح الأساسية والمفاتيح البديلة» مجاني؟

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

ماذا ستتعلم في «تصميم المفاتيح الأساسية والمفاتيح البديلة»؟

تعلّم كيف يؤثر الاختيار بين المفاتيح الطبيعية والمفاتيح البديلة المتسلسلة وUUIDs في حجم الفهرس ومعدل الإدراج والأداء العام للاستعلامات تتمرن على PostgreSQL Performance & Query Optimization مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ PostgreSQL Performance & Query Optimization؟

لا تُشترط خبرة سابقة. PostgreSQL Performance & Query Optimization على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «تصميم المفاتيح الأساسية والمفاتيح البديلة»؟

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

هل يمكنني كتابة وتشغيل أكواد في درس PostgreSQL Performance & Query Optimization هذا؟

نعم. كل درس في PostgreSQL Performance & Query Optimization يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

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

  1. المفاضلة بين التطبيع وإلغاء التطبيع
  2. اختيار أنواع البيانات المناسبة
  3. تقسيم الجداول الكبيرة
  4. تصميم المفاتيح الأساسية والمفاتيح البديلة
← العودة إلى PostgreSQL Performance & Query Optimization