کلیدهای اصلی: ID ها در مقابل GUID ها
تعریف کلید اصلی:
کلید اصلی در پایگاه داده ها برای مشخص کردن هر رکورد استفاده می شود که می تواند یک Attribute (مشخصه) باشد که تضمین می شود تکراری نیست، یا توسط پایگاه داده در هنگام ایجاد یک رکورد تولید شود. ممکن است بارها در مرحله ساخت یک جدول در پایگاه داده این سوال برای شما پیش آمده باشد که از کدام نوعِ ID درجدول استفاده کنید. پاسخ این است که: بستگی دارد، ولی در اکثر مواقع لزومی به استفاده از GUID یا همان unique identifier نیست.
انواع دادهای:
قبل از انتخاب نوع دادهای برای کلید اصلی باید درنظر گرفت که کلید اصلی قرار است چه چیزی را نمایش دهد. میتواند شماره شناسنامه فردی باشد، یا شناسه ISIN یک کتاب باشد، و یا یک عدد از یک سری متوالی باشد که تنها یک رکورد را در جدول مشخص کند. بنابراین بر اساس نوع داده ها در جدول ها باید تصمیم گرفت که از چه نوع داده ای برای کلید اصلی استفاده کنیم.
بصورت کلی انواع داده ای مناسب برای کلید اصلی موارد زیر هستند:
- عدد (smallint, bigint, bigint)
- Unique Identifiers(GUID)
- رشته (در مواردی خاص)
گزینه های نامناسب:
- رشته ها (در حالت کلی)
- تاریخ
- اعداد اعشاری (float, decimal)
- XML (به دلیل پیچیدگی بالا)
برای انتخاب نوع داده ای برای کلید اصلی باید به نکات زیر توجه کرد:
- برآوردی از رشد جدول: اینکه آیا جدول در آینده ممکن است چند رکورد در جدول مورد نظر قرار بگیرد.
- ایندکس گذاری (فهرست گذاری)
- فضای ذخیره سازی پایگاه داده
- زمان محاسبات: انواع داده ای بزرگتر بار محاسباتی بیشتری بر CPU (پردازنده) میگذارند
- سرعت عملکرد در فضای Cloud: نوع داده ای بزرگتر یعنی ترافیک بیشتر
- قابلیت محاسبه (مقایسه، جمع و ...)
در جدول زیر مقایسه ای بین رایج ترین انواع داده ای برای کلید اصلی را می بینید:
|
نوع داده ای
|
از
|
تا
|
میزان فضای ذخیره سازی
|
میزان فضای لازم برای ذخیره 1 میلارد رکورد
|
|
tinyint
|
0
|
255
|
1 byte
|
Not possible
|
|
smallint
|
-2^15
-32,768
|
2^15-1
32,767
|
2 bytes
|
Not possible
|
|
int
|
-2^3
-2,147,483,648
|
2^31-1
2,147,483,647
|
4 bytes
|
3.72 GB
|
|
bigint
|
-2^63
-9,223,372,036,854,775,808
|
2^63-1
9,223,372,036,854,775,807
|
8 bytes
|
7.45 GB
|
|
uniqueidentifier (GUID)
|
2^122
5,316,911,983,139,663,491,615,228,241,121,400,000 possible combinations
|
16 bytes
|
14 GB
|
به وضوح قابل مشاهده است که GUID از دیگر انواع داده ای فضای بیشتری اشغال میکند.
به چی فکر می کنید؟استفاده 16بایت به جای 4بایت برای کلید های اصلی..؟ آن 14 بایت اضافی به عنوان مقدار میاد اما این مقدار ممکن است به اون خوبی که فکر می کنید نباشد.
استفاده از GUID ها به عنوان مقدار شناسایی رکورد منحصر بفرد تر از عدد صحیح 32 بیتی احساس می شود. پایگاه داده guru Joe Celko بیشتر موافق به نظر می رسد. کلید های اصلی منحصر بفرد برای گنجاندن سناریو های پیشرفت توسعه مثل همانند سازی یا وقتی نیاز به کلید های اصلی خارج از پایگاه داده است اما این هنوز سوال است تعادل مبادلات بین IDهای عدد صحیح 4 بایتی مرسوم و کلید های منحصر بفرد 16بایتی.
یک جدول با کلید اصلی نوع عددی:
|
Value
|
ID
|
|
Apple
|
1
|
|
Orange
|
2
|
|
Pear
|
3
|
|
Mango
|
4
|
یک جدول با کلید اصلی نوعGUID :
|
ID
|
Value
|
|
C87FC84A-EE47-47EE-842C-29E969AC5131
|
Apple
|
|
2A734AE4-E0EF-4D77-9F84-51A8365AC5A0
|
Orange
|
|
70E2E8DE-500E-4630-B3CB-166131D35C21
|
Pear
|
|
15ED815C-921C-4011-8667-7158982951EA
|
Mango
|
مزایای GUID:
- منحصربفرد بودن در میان هر جدول، هر پایگاه داده، هر سرور
- مواردی که تعداد رکوردهای جدول بیشتر از حداکثر عددِ قابل نمایش توسط انواع داده ای کوچکتر باشد.
-
- اجازه آسان ادغام رکوردها از پایگاه های داده متفاوت
- اجازه آسان توزیع پایگاه های داده میان چندین سرور
- GUIDرا میتوان در نرم افزار تولید کرد و بدون درگیری برای تکراری بودن در پایگاه داده ذخیره کرد.
- هماهنگ سازی (Synchronization) پایگاه داده ها بدون همپوشانی و تکرار کلیدها.
معایب GUID:
- زمان محاسبه و فضای ذخیره سازی بیشتر.
- ایجاد مشکل در فرایند ایندکس گذاری در پایگاه داده.
- اینکه 4برابر بزرگ تر از مقدار ایندکس 4بایتی است.این میتونه اثر جدی روی پیامد های ذخیره سازی داشته باشد اگر مراقب نباشید.
- قابلیت خوانایی کمتر و در نتیجه سخت تر شدن رفع خطا (جایی که ID به این صورت است: '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
- تولید GUIDها باید بصورت متوالی باشد برای کارایی بهتر مانندnewsequentialid() در SQL2005 و برای استفاده از شاخص های خوشه ای.