إستخدام حقل UUID أم حقل ID متسلسل أفضل

وعليكم السلام ورحمة الله وبركاته.

الخيار الأول لك وهو إستخدام id متسلسل (INT او BIGINT) مع إضافة حقل uuid إضافي وهو الخيار الأكثر إستخداما وعملي.

id        BIGINT PRIMARY KEY AUTO_INCREMENT
uuid      UUID UNIQUE NOT NULL

فهنا :

• id هو للاستخدام الداخلي مثل joins والعلاقات .
• uuid وهو للاستخدام الخارجي مثل الروابط و ال APIs.

وهو هنا له مميزات كثيرة مثل :

• أداء أفضل في:
  • الفهارس (indexes).
  • العلاقات (foreign keys).
  • الاستعلامات الكبيرة.
• أسهل في:
  • ال debug
  • الترتيب (ORDER BY id)
• أمان أعلى:
  • فلا أحد يقدر أن يتوقع الروابط مثل /users/3 سيكون /users/550e8400-e29b-41d4-a716-446655440000 .

والخيار الثاني وهو إستخدام UUID كمفتاح أساسي (PRIMARY KEY):

id UUID PRIMARY KEY

وهو مناسب جدا لو كان لديك:

• نظام Microservices أى أكثر من خادم وخدمة.
• توليد لل ID من أكثر من خادم.
• إنشاء Offline creation مثلا تطبيق هاتف (mobile apps).

وعليكم السلام ورحمة الله وبركاته.

سؤالك في مكانه، وهذه نقطة تصميم مهمة في قواعد البيانات.

الأفضل في أغلب التطبيقات الحديثة أن تجعل الـ id المتسلسل رقمًا داخليًا فقط، وتضيف بجانبه حقل UUID مستقل، ثم تستخدم الـ UUID في الروابط وواجهات الـ API، ولا تعتمد على الـ id المتسلسل خارجيًا. بهذه الطريقة تجمع بين الأداء الجيد والأمان.

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

أما الـ UUID فهو ممتاز للاستخدام الخارجي، لأنه عشوائي وصعب التخمين، وبالتالي أكثر أمانًا عند استخدامه في الروابط أو عند التعامل مع الـ API. لكنه أبطأ نسبيًا من الـ id الرقمي، ويستهلك مساحة أكبر في الفهارس، لذلك لا يُفضل غالبًا كمفتاح أساسي وحيد في قواعد البيانات الكبيرة.

لهذا، الحل العملي الشائع هو أن يكون المفتاح الأساسي Primary Key رقمًا متسلسلًا، مع وجود حقل UUID عليه فهرس فريد، وتستخدم الـ UUID في كل ما هو ظاهر للمستخدم أو للتكامل مع الأنظمة الأخرى، بينما تبقى العلاقات الداخلية مبنية على الرقم المتسلسل.

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

عليك بالجمع بين النوعين من خلال تخصيص Serial Integer ليكون  Primary Key الداخلي مع إنشاء حقل إضافي من نوع UUID للاستخدام في الروابط الخارجية URLs،لتحسين أداء العمليات المتعلقة بالفهرسة وسرعة الربط بين الجداول Joins، وبذلك يتميز فيه الرقم المتسلسل بكونه يشغل مساحة تخزينية أقل داخل الذاكرة مقارنة بالمعرفات الطويلة، وتوفير طبقة أمنية تحمي البيانات من هجمات التخمين التي قد تحدث في حال كانت المعرفات متسلسلة في الواجهة العامة.

أي دالة تستقبل UUID من طلب الـ HTTP ثم تقوم بالاستعلام عن السجل المرتبط به، والذي يمكن تحسينه من خلال عمل Caching للمفتاح المتسلسل المقابل لذلك الـ UUID لتقليل ضغط الاستعلامات المتكررة.

أيضًا ستتمكن من تغيير المعرفات العامة مستقبلاً دون التأثير على العلاقات الداخلية بين الجداول.

وللعلم هناك إصدار جديد UUID v7 يجمع بين الزمن Timestampوبين العشوائية، أي متسلسلاً بطبعه، ولو استخدمت ذلك الإصدار فتستطيع الإعتماد عليه كـ Primary Key وحيد مباشرة دون الحاجة لـ Serial ID، لأنه يحل مشكلة بطء الفهرسة التي كانت موجودة في UUID v4 القديم.