UUID مقابل bigint في PostgreSQL: اختيار معرفات قابلة للتوسع

لماذا يهم اختيار المعرف أكثر مما يبدو

كل صف في جدول PostgreSQL يحتاج إلى طريقة مستقرة ليُعاد العثور عليه لاحقًا. هذا ما يفعله المعرف: يُعرّف السجل بشكل فريد، عادةً ما يكون المفتاح الأساسي، ويصبح الرابط للعلاقات. تخزن الجداول الأخرى المعرف كـ foreign key، تستعمله الاستعلامات للانضمام، وتُمرره التطبيقات كمقبض لـ “ذلك العميل”، “تلك الفاتورة”، أو “تذكرة الدعم”.

بما أن المعرفات تنتشر في كل مكان، فالاختيار ليس تفصيلًا تقنيًا داخليًا فقط. يظهر لاحقًا في حجم الفهارس، أنماط الكتابة، سرعة الاستعلامات، معدلات ضرب الكاش، وحتى عمل المنتج مثل التحليلات والـ imports وتصحيح الأخطاء. كما يؤثر على ما تكشفه في عناوين URL وواجهات الـ API، ومدى سهولة أن يخزن التطبيق المحمول البيانات ويتزامن بأمان.

تنتهي معظم الفرق بمقارنة UUID مقابل bigint في PostgreSQL. ببساطة، تختار بين:

• bigint: رقم 64-بت، غالبًا يُولد عبر متسلسلة (1، 2، 3...).
• UUID: معرف 128-بت، يبدو عشوائيًا عادةً، أو يُولد بطريقة مرتبة زمنياً.

لا يوجد خيار يفوز في كل الحالات. يميل الـ bigint لأن يكون مضغوطًا وملائمًا للفهارس والفرز. تناسب UUIDs الحالات التي تحتاج فيها معرفات فريدة عالمياً عبر الأنظمة، أو تريد معرفات عامة أقل قابلية للتخمين، أو تتوقع إنشاء بيانات في أماكن متعددة (خدمات متعددة، تطبيقات محمولة بدون اتصال، أو شاردينغ مستقبلية).

قاعدة إرشادية مفيدة: قرر بناءً على كيفية إنشاء ومشاركة بياناتك، وليس فقط كيف ستخزن اليوم.

أساسيات bigint و UUID بلغة بسيطة

عند مقارنة UUID مقابل bigint في PostgreSQL، أنت تختار بين طريقتين لتسمية الصفوف: رقم صغير شبيه بالعداد، أو قيمة أطول وفريدة عالمياً.

معرف bigint هو عدد صحيح 64-بت. في PostgreSQL عادةً تولده عبر عمود identity (أو النمط القديم serial). تحافظ قاعدة البيانات على sequence وتمنح الرقم التالي في كل إدخال. هذا يعني أن المعرفات تكون عادة 1، 2، 3، 4... بسيط وسهل القراءة ومناسب للأدوات والتقارير.

UUID (معرف فريد عالميًا) هو 128-بت. غالبًا تراه مكتوبًا كـ 36 حرفًا مع وُصول، مثل 550e8400-e29b-41d4-a716-446655440000. الأنواع الشائعة تشمل:

• v4: UUID عشوائي. سهل التوليد في أي مكان، لكنه لا يرتب حسب زمن الإنشاء.
• v7: UUID مرتب زمنياً. يظل فريدًا، لكنه مصمم ليتزايد تقريبًا مع مرور الوقت.

التخزين هو واحد من الفوارق العملية الأولى: bigint يستخدم 8 بايت، بينما UUID يستخدم 16 بايت. فارق الحجم هذا يظهر في الفهارس ويمكن أن يؤثر على معدلات نجاح الكاش (قاعدة البيانات تستطيع وضع عدد أقل من قيود الفهرس في الذاكرة).

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

حجم الفهرس وتضخم الجدول: ما الذي يتغير

أكبر اختلاف عملي بين bigint و UUID هو الحجم. bigint 8 بايت؛ UUID 16 بايت. هذا يبدو طفيفًا حتى تتذكر أن الفهارس تكرر معرفاتك مرات عديدة.

يجب أن يبقى فهرس المفتاح الأساسي “ساخنًا” في الذاكرة ليظهر السرعة. فهرس أصغر يعني أن جزءًا أكبر منه يناسب shared buffers وCPU cache، لذا عمليات البحث والربط تحتاج قراءات قرص أقل. مع مفاتيح UUID، يكون الفهرس عادةً أكبر بشكل ملحوظ لنفس عدد الصفوف.

المضاعف هو الفهارس الثانوية. في B-tree الخاص بPostgreSQL، كل إدخال في الفهرس الثانوي يخزن أيضًا قيمة المفتاح الأساسي (حتى تتمكن قاعدة البيانات من إيجاد الصف). لذا، معرفات أعرض تُضخّم ليس فقط فهرس المفتاح الأساسي، بل كل فهرس ثانوي تضيفه. إذا كان لديك ثلاث فهارس ثانوية، فإن الزيادة في 8 بايت من UUIDs تظهر فعليًا في أربعة أماكن.

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

عمليًا:

• عادةً ما تجعل UUIDs فهارس المفتاح الأساسي والثانوي أكبر، والفرق يتضاعف مع إضافة المزيد من الفهارس.
• الفهارس الأكبر تعني ضغطًا أكبر على الذاكرة والمزيد من قراءات الصفحات تحت الحمل.
• كلما زادت الجداول التي تشير إلى المفتاح (الأحداث، السجلات، جداول الربط)، كلما كان فرق الحجم أكثر أهمية.

إذا ظهر معرف المستخدم في users، orders, order_items, و audit_log، فذلك نفس القيمة مخزنة ومفهرسة عبر كل تلك الجداول. اختيار معرف عريض هو قرار تخزين بقدر ما هو قرار معرف.

ترتيب الفرز وأنماط الكتابة: معرفات متسلسلة مقابل عشوائية

معظم مفاتيح PostgreSQL الأساسية تجلس على فهرس B-tree. يعمل B-tree بشكل أفضل عندما تهبط الصفوف الجديدة بالقرب من نهاية الفهرس، لأن قاعدة البيانات تستطيع الإلحاق مع أقل قدر من إعادة الترتيب.

المعرفات المتسلسلة: متوقعة وودية للتخزين

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

هذا مهم حتى لو لم تشغّل ORDER BY id. مسار الكتابة لا يزال يحتاج لوضع كل مفتاح جديد في الفهرس بالترتيب.

UUIDs العشوائية: تشتت أكبر، تآكل أكثر

UUID عشوائي (شائع مع UUIDv4) يوزع الإدخالات عبر الفهرس بأكمله. ذلك يزيد احتمال page splits، حيث تضطر PostgreSQL إلى تخصيص صفحات فهرس جديدة ونقل مدخلات لصنع مساحة. النتيجة هي تضخيم الكتابة: المزيد من بايتات الفهرس مكتوبة، المزيد من WAL مولدًا، وفي كثير من الأحيان المزيد من العمل الخلفي لاحقًا (vacuum وإدارة bloat).

UUIDs المرتبة زمنياً تغير الصورة. UUIDs التي تزداد تقريبًا مع الوقت (مثل UUIDv7 أو مخططات زمنية أخرى) تستعيد الكثير من التجاور، بينما تظل 16 بايت وتبدو كـ UUIDs في الـ API.

ستشعر بهذه الاختلافات أكثر عندما يكون معدل الإدخال مرتفعًا، والجداول كبيرة لا تتسع في الذاكرة، ولديك فهارس ثانوية متعددة. إذا كنت حساسًا لارتفاعات زمن الاستجابة الناتجة عن page splits، تجنّب المعرفات العشوائية بالكامل على جداول الكتابة الساخنة.

مثال: جدول أحداث مشغول يستقبل سجلات تطبيق محمول طوال اليوم عادةً سيعمل بسلاسة أكثر مع مفاتيح متسلسلة أو UUIDs مرتبة زمنياً مقارنة بـ UUIDs عشوائية تمامًا.

أثر الأداء الذي يمكنك فعلاً ملاحظته

معظم التباطؤ في العالم الحقيقي ليس “UUIDs بطيئة” أو “bigints سريعة”. إنه يتعلق بما تضطر قاعدة البيانات لمسه لتجيب على استعلامك.

خطط الاستعلام تهتم أساسًا بمدى قدرتها على استخدام فهرس للفلترة، أداء الانضمامات السريعة على المفتاح، وما إذا كان الجدول منظمًا فيزيائيًا (أو قريبًا بما يكفي) لجعل قراءات النطاق رخيصة. مع مفتاح أساسي bigint، تهبط الصفوف الجديدة بترتيب متزايد تقريبًا، لذا يظل فهرس المفتاح الأساسي مضغوطًا وملائمًا للتجاور. مع UUIDs عشوائية، تتناثر الإدخالات عبر الفهرس، ما قد يخلق المزيد من page splits وترتيبًا أقل انتظامًا على القرص.

القراءات هي المكان الذي يلاحظه كثير من الفرق أولًا. المفاتيح الأكبر تعني فهارس أكبر، والفهارس الأكبر تعني صفحات مفهرس أقل تناسب الذاكرة. هذا يقلل من معدلات نجاح الكاش ويزيد IO، خصوصًا في شاشات التحميل الكثيف مثل “قائمة الطلبات مع معلومات العميل”. إذا لم يناسب working set الذاكرة، قد تدفع مخططات غنية بالـ UUIDs نظامك لتجاوز هذه النقطة مبكرًا.

الكتابات قد تتغير أيضًا. إدخالات UUID العشوائية يمكن أن تزيد التآكل في الفهرس، مما يضيف ضغطًا على autovacuum ويمكن أن يظهر كقِطع في الكمون خلال فترات الذروة.

إذا قمت بقياس UUID مقابل bigint في PostgreSQL، اجعل المقارنة عادلة: نفس المخطط، نفس الفهارس، نفس الـ fillfactor، وعدد صفوف يكفي لتجاوز الذاكرة (ليس 10k). قِس زمن الاستجابة p95 وIO، واختبر كلًا من الكاش الدافئ والبارد.

إذا بنت تطبيقات باستخدام AppMaster على PostgreSQL، يظهر هذا غالبًا كصفحات قائمة أبطأ وحِمل أكبر على قاعدة البيانات قبل أن يتحول إلى "مشكلة CPU".

الأمان وسهولة الاستخدام في الأنظمة المواجهة للعامة

إذا خرجت معرفاتك من قاعدة البيانات وظهرت في عناوين URL، استجابات API، تذاكر الدعم، وشاشات المحمول، فإن الاختيار يؤثر على كل من الأمان وقابلية الاستخدام اليومية.

معرفات bigint سهلة للبشر. قصيرة، يمكنك قراءتها عبر الهاتف، وفريق الدعم يمكنه بسرعة ملاحظة أنماط مثل "كل الطلبات الفاشلة حول 9,200,000." هذا يسرع التصحيح، خصوصًا عند العمل من السجلات أو لقطات الشاشة من العملاء.

UUIDs مفيدة عند تعريض المعرفات للعامة. UUID يصعب تخمينه، لذا المحاولات البسيطة مثل التجريب بـ /users/1, /users/2 لا تنجح. كما يصعب على الأطراف الخارجية استنتاج عدد السجلات لديك.

الفخ هو التفكير أن "عدم القابلية للتخمين" يعني "أمان". إذا كانت فحوصات التفويض ضعيفة، يمكن إساءة استخدام معرفات bigint المتوقعة بسرعة، لكن UUIDs يمكن أن تُسرق من رابط مشترك، سجل مسرب، أو استجابة API مخزنة مؤقتًا. الأمان يجب أن يأتي من فحوصات الصلاحيات، ليس من إخفاء المعرف.

نهج عملي:

• فرض امتلاك/فحوص دورية على كل قراءة وكتابة.
• إذا كشفت المعرفات في واجهات عامة، استخدم UUIDs أو رموز عامة منفصلة.
• إذا أردت مراجع سهلة للبشر، احتفظ بـ bigint داخليًا لعمليات التشغيل.
• لا تُشفر معنى حساسًا داخل المعرف نفسه (مثل نوع المستخدم).

مثال: بوابة العملاء تعرض أرقام الفواتير. إذا استخدمت الفواتير bigint وAPI يتحقق فقط من "وجود الفاتورة"، يمكن لأحد تكرار الأرقام وتنزيل فواتير الآخرين. أصلح الفحص أولًا. بعدها قرر ما إذا كانت UUIDs للمعرفات العامة تقلل المخاطر وحِمل الدعم.

في منصات مثل AppMaster، حيث تتدفق المعرفات عبر APIs المولّدة والتطبيقات المحمولة، الافتراضي الأكثر أمانًا هو التحقق المتسق بالإضافة إلى نمط معرف يمكن للعملاء التعامل معه بثبات.

كيف تتدفق المعرفات عبر الـ APIs والتطبيقات المحمولة

نوع قاعدة البيانات الذي تختاره لا يبقى داخل القاعدة فقط. يتسرب إلى كل الحدود: عناوين URL، حِمولات JSON، تخزين العميل، السجلات، والتحليلات.

إذا قمت بتغيير نوع المعرف لاحقًا، فالاتلاف نادرًا ما يكون "ترحيلًا بسيطًا". يجب تغيير المفاتيح الأجنبية في كل مكان، وليس فقط في الجدول الرئيسي. قد يعيد الـ ORM أو مولد الكود توليد النماذج، لكن التكاملات ما زالت تتوقع التنسيق القديم. حتى نقطة النهاية البسيطة GET /users/123 تصبح فوضوية عندما يصبح المعرف 36 حرفًا. عليك أيضًا تحديث الكاشات، طوابير الرسائل، وأي مكان خُزنت فيه المعرفات كأعداد.

لواجهات الـ API، الاختيار الأكبر هو التنسيق والتحقق. تنتقل bigints كأرقام، لكن بعض الأنظمة (وبعض اللغات) قد تواجه مشكلات الدقة عند قيم كبيرة إذا حللتها كأعداد عائمة. تنتقل UUIDs كسلاسل، وهو أكثر أمانًا للتحليل، لكن تحتاج تحققًا صارمًا لتفادي وصول "UUID تقريبًا" إلى السجلات.

على المحمول، تُسلسل المعرفات وتُخزن باستمرار: استجابات JSON، جداول SQLite محلية، وطوابير غير متصلة تحفظ الإجراءات حتى يعود الشبك. المعرفات الرقمية أصغر، لكن UUIDs كسلاسل غالبًا أسهل للتعامل معها كرموز غامضة. ما يسبب ألمًا فعليًا هو عدم الاتساق: طبقة تخزنها كعدد، وأخرى كنص، وتصبح المقارنات أو الانضمامات هشة.

بعض القواعد لتجنب المشاكل:

• اختر تمثيلًا رسميًا واحدًا للـ API (غالبًا السلسلة) والتزم به.
• تحقق من المعرفات عند الحواف وأِرجع أخطاء 400 واضحة.
• خزّن نفس التمثيل في الكاش المحلي وطوابير العمل غير المتصلة.
• سجّل المعرفات بأسماء حقول وتنسيقات متسقة عبر الخدمات.

إذا كونت عملاء ويب ومحمول مع ستاك مولَّد (مثل AppMaster الذي يولد backend وتطبيقات أصلية)، يصبح عقد المعرف الثابت أكثر أهمية لأنه جزء من كل نموذج وطلب مولد.

جاهزية الشاردينغ والأنظمة الموزعة

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

تحظى UUIDs بشعبية في إعدادات متعددة المناطق أو متعددة الكتابة لأن أي عقدة يمكنها توليد معرف فريد دون سؤال sequence مركزي. يقلل ذلك التنسيق ويجعل قبول الكتابات في مناطق مختلفة ودمج البيانات لاحقًا أسهل.

لا يزال بإمكان bigint العمل، لكن تحتاج تخطيطًا. الخيارات الشائعة تشمل تخصيص نطاقات رقمية لكل شارد (الشارد 1 يستخدم 1-1B، الشارد 2 يستخدم 1B-2B)، تشغيل sequences منفصلة مع بادئة شارد، أو استخدام معرفات على غرار Snowflake (بتات زمنية + بتات آلة أو شارد). هذه تحافظ على فهارس أصغر من UUIDs وتحافظ على بعض الترتيب، لكنها تضيف قواعد تشغيلية يجب تنفيذها.

المقايضات اليومية المهمة:

• التنسيق: UUID يحتاج تقريبًا لا شيء؛ bigint غالبًا يحتاج تخطيط نطاقات أو خدمة مولدة.
• التصادمات: تصادمات UUID نادرة جدًا؛ bigint آمن فقط إذا لم تتداخل قواعد التخصيص.
• الترتيب: كثير من مخططات bigint مرتبة تقريبًا زمنياً؛ UUID غالبًا عشوائي إلا إن استخدمت نسخة مرتبة زمنياً.
• التعقيد: bigint المشارد يبقى بسيطًا فقط إذا كان الفريق منضبطًا.

لكثير من الفرق، "جاهزية الشاردينغ" تعني فعليًا "جاهزية الترحيل". إذا كنت على قاعدة بيانات واحدة اليوم، اختر المعرف الذي يسهل العمل الحالي. إذا تبنيت بالفعل كتّابًا متعددين (مثلاً عبر APIs وتطبيقات محمولة في AppMaster)، قرر مبكرًا كيف تُنشأ وتتحقق المعرفات عبر الخدمات.

خطوة بخطوة: اختيار استراتيجية المعرف المناسبة

ابدأ بتسمية الشكل الحقيقي لتطبيقك. قاعدة بيانات PostgreSQL واحدة في منطقة واحدة لها احتياجات مختلفة عن نظام متعدد مستأجرين، إعداد قد ينقسم لاحقًا بحسب المنطقة، أو تطبيق محمول يحتاج لإنشاء سجلات أوفلاين ومزامنتها لاحقًا.

بعدها كن صريحًا حول مكان ظهور المعرفات. إذا بقيت المعرفات داخل الـ backend (وظائف، أدوات داخلية، لوحات إدارة)، فالبساطة غالبًا تفوز. إذا ظهرت المعرفات في عناوين URL، سجلات مشاركة مع العملاء، تذاكر الدعم، أو روابط عميقة في المحمول، فالتوقعية والخصوصية تصبح أكثر أهمية.

استخدم الترتيب كعامل تقرير، لا كفكرة لاحقة. إذا اعتمدت على خلاصات "الأحدث أولًا"، ترقيم الصفحة المستقر، أو سجلات تدقيق سهلة الفحص، تقلل المعرفات المتسلسلة (أو المعرفات المرتبة زمنياً) المفاجآت. إذا لم يكن الترتيب مرتبطًا بالمفتاح الأساسي، يمكنك إبقاء اختيار PK منفصلًا والفرز بواسطة timestamp بدلًا من ذلك.

تدفق قرار عملي:

1. صنّف البنية (قاعدة بيانات واحدة، متعدد مستأجرين، متعدد مناطق، أو أوفلاين أولًا) وإمكانية دمج البيانات من مصادر متعددة.
2. قرر إن كانت المعرفات معرفات عامة أو داخلية فقط.
3. أكد متطلبات الفرز والتجزيء. إذا تحتاج ترتيب الإدخال الطبيعي، تجنب المعرفات العشوائية تمامًا.
4. إذا اخترت UUIDs، اختر إصدارًا بقصد: عشوائي (v4) لعدم التوقع، أو مرتب زمنياً لتحسين تجاور الفهرس.
5. ثبّت القواعد مبكرًا: صيغة نصية رسمية، قواعد حالة الأحرف، التحقق، وكيف تُرجع وتستقبل كل API المعرفات.

مثال: إذا أنشأ تطبيق محمول "طلبات مسودة" أوفلاين، تتيح UUIDs للجهاز توليد معرفات بأمان قبل أن يرى الخادم السجل. في أدوات مثل AppMaster، هذا أيضًا مريح لأن نفس صيغة المعرف تتدفق من القاعدة إلى الـ API إلى الويب والتطبيقات الأصلية دون استثناءات.

أخطاء شائعة وفخاخ لتجنبها

تفشل معظم مناظرات المعرفات لأن الناس يختارون نوعًا لسبب واحد، ثم يُفاجأون بتأثيراته الجانبية لاحقًا.

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

مشكلة متكررة أخرى هي خلط أنواع المعرفات عبر الخدمات والعملاء. على سبيل المثال، خدمة تستخدم bigint، وأخرى تستخدم UUID، وينتهي الأمر بواجهة API تحتوي على معرفات رقمية ونصية. هذا يتحول غالبًا إلى أخطاء دقيقة: محللات JSON تفقد الدقة على الأعداد الكبيرة، كود الجوال يعامل المعرفات كأرقام في شاشة ونصوص في أخرى، أو مفاتيح الكاش لا تتطابق.

فخ ثالث هو اعتبار "المعرفات غير القابلة للتخمين" كبديل للتفويض. حتى مع UUIDs، ما زلت بحاجة لفحوصات صلاحية صحيحة.

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

لتجنب الألم:

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

إذا تبنيت منصة مولِّدة للكود مثل AppMaster، تصبح الاتساق أكثر أهمية لأن نفس نوع المعرف يتدفق من مخطط القاعدة إلى الـ backend المولَّد وإلى تطبيقات الويب والمحمول.

قائمة تحقق سريعة قبل أن تقرر

إذا شعرت بالارتباك، لا تبدأ بالنظرية. ابدأ بما سيبدو عليه المنتج خلال عام، وعدد الأماكن التي ستنتقل فيها تلك المعرفات.

اسأل:

• كم سيكبر أكبر جدول في 12 إلى 24 شهرًا، وهل ستحتفظ بسنوات من السجل؟
• هل تحتاج معرفات تقريبًا مرتبة حسب وقت الإنشاء لسهولة الترحيل والفرز؟
• هل سيُنشئ أكثر من نظام واحد سجلات في نفس الوقت، بما في ذلك تطبيقات محمولة أوفلاين أو مهام خلفية؟
• هل سيظهر المعرف في عناوين URL، تذاكر الدعم، التصديرات، أو لقطات شاشة مشتركة مع العملاء؟
• هل يمكن لكل عميل أن يتعامل مع المعرف بنفس الطريقة (ويب، iOS، Android، سكربتات)، بما في ذلك التحقق والتخزين؟

بعد الإجابة، تحقق من التجهيزات. إذا استخدمت bigint، تأكد من وجود خطة واضحة لتوليد المعرف في كل بيئة (خاصة التطوير المحلي وعمليات الاستيراد). إذا استخدمت UUID، تأكد أن عقود الـ API ونماذج العملاء تتعامل مع المعرفات كسلاسل بشكل متسق، وأن الفريق مرتاح لقراءتها ومقارنتها.

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

إذا بنيت على AppMaster، قرر مبكرًا لأن عقد المعرف يتدفق عبر نموذج PostgreSQL، الـ APIs المولَّدة، وعميل الويب والمحمول معًا.

سيناريو واقعي

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

مع bigint، تكون حِمولات الـ API مضغوطة وسهلة القراءة:

{ "ticket_id": 4821931, "customer_id": 91244 }

الترقيم يجعل الترقيم الطبيعي بسيطًا: ?after_id=4821931&limit=50. الفرز حسب id عادةً يطابق وقت الإنشاء، لذا "أحدث التذاكر" سريع ومتوقع. التصحيح أيضًا سهل: يمكن للدعم أن يطلب "التذكرة 4821931" ومعظم الناس يكتبونها بدون أخطاء.

مع UUIDs، تصبح الحِمولات أطول:

{ "ticket_id": "3f9b3c0a-7b9c-4bf0-9f9b-2a1b3c5d1d2e" }

إذا استخدمت UUID v4 عشوائي، تهبط الإدخالات في جميع أنحاء الفهرس. هذا يمكن أن يعني مزيدًا من تآكل الفهرس وتجربة تصحيح أكثر فوضوية (النسخ/اللصق يصبح المعتاد). غالبًا تتحول الترقيمات إلى cursors بدلاً من "بعد id" البسيط.

إذا استخدمت UUIDs مرتبة زمنياً، تحتفظ بمعظم سلوك "الأحدث أولًا" بينما تتجنب معرفات قابلة للتخمين في عناوين URL العامة.

في الواقع، تلاحظ الفرق الفرق عادةً في أربعة أشياء:

• كم مرة تُكتب المعرفات باليد مقابل نسخها
• ما إذا كان "الفرز حسب id" يطابق "الفرز حسب created"
• مدى سلاسة ترقيم المؤشر (cursor pagination)
• سهولة تتبع سجل واحد عبر السجلات، استدعاءات API، وشاشات المحمول

الخطوات التالية: اختر افتراضيًا، اختبر، وثبّت معايير

معظم الفرق تتعثر لأنهم يريدون الجواب المثالي. لا تحتاج الكمال. تحتاج افتراضيًا يناسب منتجك اليوم، وطريقة سريعة لإثبات أنه لن يضر لاحقًا.

قواعد يمكنك توثيقها:

• استخدم bigint عندما تريد أصغر فهارس، ترتيبًا متوقعًا، وتصحيحًا سهلًا.
• استخدم UUID عندما يجب أن تكون المعرفات صعبة التخمين في العناوين العامة، تتوقع الإنشاء أوفلاين (محمول)، أو تريد تقليل التصادمات عبر الأنظمة.
• إذا قد تقسم البيانات حسب مستأجر أو منطقة لاحقًا، فضّل خطة معرف تعمل عبر العقد (UUID، أو مخطط bigint منسق).
• اختر واحدًا كافتراضي واجعل الاستثناءات نادرة. الاتساق عادةً يفوق التحسين الجزئي لكل جدول.

قبل الحسم، قم بتجربة صغيرة. أنشئ جدولًا بحجم صف واقعي، أدخل 1 إلى 5 ملايين صف، وقارن (1) حجم الفهرس، (2) زمن الإدخال، و(3) بعض الاستعلامات الشائعة مع المفتاح الأساسي وعدد قليل من الفهارس الثانوية. نفّذ الاختبار على العتاد الحقيقي وشكل بياناتك الفعلي.

إذا كنت قلقًا من تغيير لاحق، خطط ترحيلًا يجعل العملية مملة:

• أضف عمود معرف جديد وفهرس فريد.
• اكتب مزدوجًا: املأ كلا المعرفين للسجلات الجديدة.
• عدّل السجلات القديمة على دفعات.
• حدّث الـ APIs والعملاء لقبول المعرف الجديد (حافظ على القديم أثناء الانتقال).
• قم بتحويل القراءة، ثم احذف المفتاح القديم عندما تبدو السجلات والقياسات نظيفة.

إذا بنيت على AppMaster (appmaster.io)، يجدر بك الحسم مبكرًا لأن اتفاقية المعرف تتدفق عبر نموذج PostgreSQL، الـ APIs المولَّدة، وتطبيقات الويب والمحمول المولَّدة. نوع المعرف مهم، لكن الاتساق عادةً أهم بمجرد وجود مستخدمين حقيقيين بعدة عملاء.