انتخاب کلید اصلی در دیتابیس (How to Choose a Good Primary Key)

در SQL Database، کلید اصلی یک بخش ضروری از هر جدول است. اگر می‌خواهیم سادگی، سازگاری و عملکرد را تضمین کنیم، برای انتخاب کلید اصلی مناسب هر جدول، باید عوامل مختلفی را در نظر بگیریم.

عوامل موثر در انتخاب کلید اصلی

یکتا بودن: (Uniqueness)

این مهمترین ویژگی است که باعث می‌شود ردیف های ستون کلید اصلی مقادیر یکسان نداشته باشند. (میدانیم که کلید اصلی نمی‌تواند Null باشد)

ثبات: (Stability)

تعریف (یعنی ستون یا ستون هایی که کلید اصلی را تشکیل می دهند) و مقادیر نباید تغییر کنند. تغییر ستون‌های PK به معنی تعریف دوباره همه کلیدهای خارجی متصل به PK است، در حالی که برای تغییر مقدار ستون PK میبایست تمام ردیف‌های متصل (FK) تغییر کنند.

تقلیل ناپذیری: (Irreducibility)

اگر از یک کلید اصلی ترکیبی استفاده می‌کنید، هیچ ستون یا ترکیب کوچک‌تری از ستون‌ها نباید ویژگی‌های جدول را به‌طور منحصربه‌فرد شناسایی کنند. به عبارت دیگر، اگر ستونی را از PK حذف کنید، ترکیب باید یکتا نباشد. به خاطر داشته باشید که اگر کلید اصلی ترکیبی را انتخاب کنید، کلید اصلی شما پیچیده‌تر خواهد بود و از منابع بیشتری (ذخیره‌سازی و حافظه) استفاده می‌کند.

سادگی: (Simplicity)

تا جایی که ممکن است از ستون های کمتری استفاده کنید و ستون هایی را انتخاب کنید که مقادیر آنها به راحتی خوانده شوند.

ستون هایی که مقادیر آنها برای انسان قابل فهم باشد، باعث آسونتر شدن مدیریت/کاربا دیتابیس می شود. برای مثال مقادیر ستون name در جدول Artist بطور واضح در مورد نام آرتیست میباشد. اما مقادیر ستون Category بطور واضح مشخص نیست در مورد چه دسته بندی می باشند. دسته بندی ملیت، جنسیت، وزن و ....

کلیدهای اصلی را می توان به دو دسته اصلی تقسیم کرد:

۱. کلیدهای جانشین (Surrogate Keys)

از یک یا چند ستون جدول توسط سیستم تولید می‌شود. این کلیدها ارتباط طبیعی با ستون های دیگر جدول ندارند و معمولا هنگام اجرا و دقیقا قبل از وارد کردن رکوردها به جدول ایجاد می شوند.

برای مثال ستون شماره سریال در جدول محصول.

۲. کلیدهای طبیعی (Natural keys)

یک یا چندستون که از قبل در جدول وجود دارند. این کلیدها با بقیه ستون های جدول رابطه طبیعی دارند.

برای مثال ستون کدملی در جدول کاربران.

سایز و نوع داده کلید اصلی

اگر کلید طبیعی را انتخاب شده باشد سایز و نوع داده کلید براساس نوع داده مقادیری است که باید در ستون کلید طبیعی ذخیره شود.

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

پرکاربردترین انواع داده برای کلیدهای اصلی عبارتند از:

1. عددی (Numeric)

این ساده ترین انتخاب است. از فضای کمتری نسبت به سایر انواع داده (معمولاً 1-8 بایت) استفاده می کند، بنابراین هم باعث صرفه جویی در ذخیره سازی و هم بهبود JOIN و LOOKUP می شود.

2. UUID/GUID (Universally Unique Identifier/Globally Unique Identifier)

برای پر کردن خودکار مناسب است، اما برای کاربران کمی گیج کننده. کلیدها به 16 بایت فضای ذخیره سازی نیاز دارند (و برای انجام JOIN و LOOKUP به حافظه بیشتری نیاز دارند). UUID ها و GUID ها برای محیط های توزیع شده عالی هستند.

"" انتخاب درست اندازه و نوع داده Surrogate Key اهمیت زیادی دارد ""

تصمیم گیری در مورد کلید اصلی

کلید جانشین یا کلید طبیعی؟ یک پاسخ برای این سوال وجود دارد: بستگی دارد.

اگر کسی سعی کرد شما را متقاعد کند که باید فقط کلیدهای طبیعی یا کلیدهای جایگزین داشته باشید، فقط لبخند بزنید :)

قبل از هرچیزی به یاد داشته باشید:

اگر کلید طبیعی را انتخاب کرده اید و ممکن است مقادیر ستون یا ستون‌های آن تغییر کند، باید آن مقادیر را در تمام جداول با کلیدهای خارجی متصل به آن کلید طبیعی به روز کنید.

اگر یک کلید اصلی از چندین ستون تشکیل شده باشد، کلیدهای خارجی شما نیز چند ستونی خواهند بود. تجربه دیگران نشان می دهد که کلیدهای اولیه با بیش از 2 ستون غیر منطقی هستند. مدل دیتابیس غیرقابل خواندن می شود، پرس و جو از داده ها خسته کننده است، و در نهایت ... یک طراح DB کار بیشتری برای انجام دارد :)

تجربه مهندس ها میگه هر زمان که مقادیر Natural keys ممکن است تغییر کند یا زمانی که یک Natural key بیش از حد پیچیده است، از یک Surrogate Key استفاده کنید. فقط به این مثال نگاه کنید:

جدول کشور کاملاً قابل فهم است. Natural key جدول city باید هم name و هم country_name باشد زیرا ممکن است شهرهای زیادی با یک نام در کشورهای مختلف وجود داشته باشد. در مورد جدول street و adress هم نیاز به کلید اصلی با دو ستون داریم. در مورد خیابان و آدرس جداول هم همینطور است. در نهایت با جدول company که ۴ ستون کلید خارجی دارد مواجه می شویم.

جدا از هزینه جست و جو در این دیتابیس تصور کنید شهرداری تصمیم گرفت نام یکی از شهرها رو تغییر بده :)) در این صورت هزینه update کردن دیتابیس خیلی سنگین میشه.

اما استفاده از Surrogate Keys تمام مشکلات بالا رو از بین خواهد برد: تصویر پایین.

ممکن است موارد بالا را به اینجوری تفسیر کنید که Surrogate Key همیشه بهتر از Natural key هستند. این درست نیست. اصولاً استفاده از Surrogate Key گاهی بی معنی است. اگر یک جدول فنی با کدهای غیرقابل تغییر دارید، نیازی به اضافه کردن ستون غیر ضروری برای Surrogate Key نیست. اگر یک Natural key از تعداد کمی ستون (در حالت ایده آل فقط یک ستون) تشکیل شده است و مقادیر آن تغییر نمی کند - از آن به عنوان یک Natural key استفاده کنید.

در نهایت، برای کسانی که در مورد استفاده از Surrogate Key تردید دارند، توجه داشته باشید که حتی در دنیای واقعی نیز نمونه‌های زیادی از این شناسه‌ها وجود دارد. شماره تامین اجتماعی، شماره بارکد، شناسه گواهینامه رانندگی و .... همه آنها مجموعه ای از اعداد بی معنی هستند.