اوایل که کار با پایگاه داده و فریمورک هایی مثل NestJS و TypeORM را شروع کرده بودم، تقریباً تمام Entityهایی که می ساختم از یک شناسه عددی ساده استفاده می کردند.

@PrimaryGeneratedColumn()
id: number;

راستش را بخواهید، در آن زمان دلیلی هم برای انتخاب گزینه ای غیر از این نمی دیدم. همه چیز ساده بود؛ رکورد اول شناسه 1 داشت، رکورد بعدی 2 و به همین ترتیب شناسه ها افزایش پیدا می کردند.

اما هرچه بیشتر با طراحی APIها و پروژه های بزرگ تر سروکار پیدا کردم، بیشتر با مفهوم UUID آشنا شدم و کم کم متوجه شدم که دلیل استفاده از آن فقط متفاوت بودن ظاهرش نیست.

شناسه های عددی؛ انتخابی که تقریباً همه با آن شروع می کنند

شناسه های عددی همان چیزی هستند که اکثر ما از ابتدای کار با دیتابیس ها با آن ها آشنا شده ایم.

1
2
3
4
5
...

سادگی، خوانایی بالا و عملکرد مناسب باعث شده اند که این روش همچنان یکی از محبوب ترین انتخاب ها باشد.

به همین دلیل، هنوز هم در بسیاری از پروژه های کوچک و متوسط، استفاده از شناسه های عددی را کاملاً منطقی می دانم.

اولین مواجهه من با UUID

اولین باری که با UUID روبه رو شدم، ظاهر آن کمی عجیب به نظر می رسید.

550e8400-e29b-41d4-a716-446655440000

در نگاه اول، این رشته طولانی در مقایسه با یک عدد ساده مثل 15 کمی غیرضروری به نظر می رسید.

خود من هم در ابتدا این سؤال را داشتم که اگر شناسه های عددی به خوبی کار می کنند، پس اصلاً چه نیازی به چنین چیزی وجود دارد؟

اما هرچه بیشتر با پروژه های واقعی و معماری های بزرگ تر آشنا شدم، دلیل وجود UUID برایم روشن تر شد.

چیزی که بیشتر توجهم را جلب کرد

یکی از ویژگی های شناسه های عددی این است که به راحتی قابل حدس هستند.

برای مثال، اگر در یک API آدرس زیر وجود داشته باشد:

/users/1

حدس زدن وجود آدرس های زیر چندان دشوار نیست:

/users/2
/users/3
/users/4

اما هنگام استفاده از UUID شرایط متفاوت می شود.

/users/550e8400-e29b-41d4-a716-446655440000

در این حالت، حدس زدن شناسه رکوردهای دیگر تقریباً غیرممکن خواهد بود.

جایی که اهمیت UUID بیشتر مشخص می شود

به مرور زمان متوجه شدم که ارزش واقعی UUID بیشتر در پروژه های بزرگ، سیستم های توزیع شده و معماری های مبتنی بر Microservice مشخص می شود.

در چنین شرایطی، ممکن است چند سرویس مختلف به صورت مستقل داده تولید کنند و وجود شناسه هایی که احتمال تکرار آن ها تقریباً صفر باشد، اهمیت زیادی پیدا می کند.

به همین دلیل، در این نوع پروژه ها معمولاً استفاده از UUID انتخاب منطقی تری محسوب می شود.

آیا همیشه باید سراغ UUID رفت؟

به نظر من، خیر.

هنوز هم در بسیاری از پروژه های شخصی و حتی برخی پروژه های کاری، استفاده از شناسه های عددی را ترجیح می دهم.

چون:

خوانایی بیشتری دارند.
فضای کمتری اشغال می کنند.
کار با آن ها ساده تر است.
از نظر عملکرد، کمی سریع تر هستند.

به همین خاطر، استفاده از UUID لزوماً به معنای حرفه ای تر بودن یک پروژه نیست و استفاده از شناسه های عددی هم به معنای قدیمی بودن طراحی محسوب نمی شود.

مقایسه مزایا و معایب

بعد از مدتی کار کردن با هر دو روش، به نظرم مهم ترین تفاوت های آن ها را می توان به شکل زیر خلاصه کرد:

ویژگی	شناسه عددی (ID)	UUID
خوانایی	بسیار ساده و خوانا	رشته های طولانی تر
سرعت	کمی بیشتر	کمی کمتر
فضای اشغال شده	کمتر	بیشتر
قابلیت حدس زدن	زیاد	تقریباً غیرممکن
مناسب برای سیستم های توزیع شده	محدود	بسیار مناسب
مناسب برای معماری `Microservice`	محدود	بسیار مناسب
امنیت در APIهای عمومی	کمتر	بیشتر
سادگی پیاده سازی	بیشتر	کمی پیچیده تر

البته این جدول به این معنا نیست که یکی از این دو روش از دیگری بهتر است. هر کدام برای شرایط خاصی طراحی شده اند و انتخاب نهایی بیشتر به نیاز پروژه بستگی دارد.

در نهایت، انتخاب مناسب به نیاز پروژه بستگی دارد

مهم ترین چیزی که در این مدت یاد گرفته ام، این است که پاسخ قطعی برای این سؤال وجود ندارد.

اگر قرار باشد یک پروژه معمولی با NestJS و PostgreSQL پیاده سازی کنم، احتمال زیادی وجود دارد که همچنان سراغ شناسه های عددی بروم.

اما اگر با APIهای عمومی، چند سرویس مستقل یا سیستم های بزرگ تر سروکار داشته باشم، احتمالاً انتخاب اول من استفاده از UUID خواهد بود.

در نهایت، هر دو رویکرد هدف مشترکی دارند؛ ایجاد یک شناسه یکتا برای رکوردهای پایگاه داده.

تفاوت اصلی، بیشتر به نیاز پروژه و شرایطی برمی گردد که قرار است آن پروژه در آن اجرا شود.

تفاوت UUID و ID عددی؛ مقایسه مزایا، معایب و کاربردها

مانی هوشیاری پور

نظرات