تفاوت فیلد unique با primary

[saeeedft]

با سلام، دوستان تفاوت فیلد uniq با فیلدی که اونو primary میگیریم در چی هستش؟ اگه بشه یه مثال ساده بزنید و این دو رو با هم مقایسه کنید تا بهتر درک بشه که ممنون میشم

[محمد سلیم آبادی]

سلام،
از جهت یکتا بودن هر دو یکتا هستند ولی از لحاظ کاربرد متفاوت اند. بطور مثال یک جدول ممکن است برای
جامعیت اطلاعات نیاز به چندین composite unique key constraint داشته باشد ولی یک کلید اصلی دارد که در جداول دیگر به آن ارجاع صورت می گیرد.

[saeeedft]

ببخشید، این uniq منظور همون index uniq هستش؟؟

[محمد سلیم آبادی]

خیر منظور من از Unique در واقع قید کلید یکتا (Unique key constraint) است، اگر منظور شما هم از واژه Unique همین باشد برایتان یک مثال آماده کرده ام که تفاوت کلید اصلی را با کلید یکتا مشخص می کند.

این مثالی است که من برای تفکیک کلید اصلی با کلید یکتا استفاده می کنم:
درست است ما کلید های اصلی ترکیبی و دنباله ی آن کلید های خارجی ترکیبی داریم ولی در عمل کمتر جایی دیدم که اینگونه جداول را طراحی کنند.
فرض کنید در حال طراحی بانک سیستم آموزشی دانشگاه هستیم. یکی از جدول های مهم جدول "گروههای درسی" است که مثلا شامل ستون های زیر است:
1. کلید جدول (id)
2. کد استاد
3. کد درس
4. کد کلاس
5. زمان
6. نیم سال
حالا فرض کنید ستون کلید اصلی را حذف کنیم، برای اینکه داده های تکراری ایجاد نشوند مجبور هستیم که ترکیبی از چند ستون را به عنوان کلید اصلی در نظر بگیریم. حالا بنظر شما ترکیب کدام از این ستون ها کلید خواهد بود؟
آیا ترکیب ستون های "کد استاد" و "زمان" و "نیم سال" ؟
یا ترکیب ستون های "کد کلاس" و "زمان" و "نیم سال"؟
آیا یک استاد در یک زمان و در یک ترم می تواند دو گروه درسی ارائه دهد؟
آیا در یک کلاس در یک ترم و یک زمان می شود دو گروه درسی ارائه داد؟
از طرفی اگر تمام ستون ها را به عنوان کلید اصلی قرار دهیم ممکن است داده های غیر معتبری ذخیره شوند. در اینجاست که یک ستون به عنوان کلید اصلی طراحی می کنیم و دو قید کلید یکتای ترکیبی برای جامعیت در نظر می گیریم.
پس یکی از تفاوت های کلید اصلی با کلید یکتا این است که: یک جدول، تنها یک کلید اصلی می تواند داشته باشد ( که ممکن است ترکیبی باشد) ولی می تواند به تعداد زیادی کلید unique داشته باشد.

[saeeedft]

من از حرفهای شما این نتیجه رو گرفتم که در صورتی که فیلد ها به صورت یونیک در نظر گرفته بشن، انعطاف پذیری در وارد کردن دادها به نوعی بیشتر میشه مثلا یه استاد در یه ترم میتونه 2 تا درس از دو گروه اموزشی داشته باشه(تا اینجا دوتا از فیلدها مشترکند اما زمان ان ها باید به هم متفاوت باشد و این تغییر در زمان باعث یونیک شدن اون رکورد خاص میشه اگه اشتباهی تو برداشتم است منون میشم بگید،

[محمد سلیم آبادی]

در حقیقت با unique کردن چند ستون در یک جدول، ما تعداد سطرهای (نمونه های) ممکن برای درج را محدود تر خواهیم کرد.

انعطاف پذیری در وارد کردن دادها به نوعی بیشتر میشه
پس جمله ی فوق بر عکس خواهد بود!

[AminSobati]

دوست عزیزم،
PK و Unique Key هر دو برای جامعیت اطلاعات استفاده میشن اما:
- هر جدول تنها یک PK میتواند داشته باشد ولی UK بیش از یکی
- فیلد PK به هیچ عنوان Null نمیپذیرد ولی فیلد UK مثل یک Value یک بار قبول میکنه (یا میتونه Allow Null باشه)

فرضا در جدول دانشجوها، یک StudentID که فرضا فیلد Identity هست ممکنه PK باشه، از طرفی اگر نیاز دارین فیلد "شماره ملی" هم داشته باشید و از یونیک بودنش اطمینان حاصل کنین، مجاز به تعریف PK دوم نخواهید بود بلکه باید UK تعریف کنید.
ضمنا Unique Index و Unique Constraint یکی نیستند و تفاوتهای ظریفی دارند. اما از SQL Server 2000 به بعد مایکروسافت استفاده از Unique Constraint به جای Unique Index رو پیشنهاد کرد.

[saeeedft]

در حقیقت با unique کردن چند ستون در یک جدول، ما تعداد سطرهای (نمونه های) ممکن برای درج را محدود تر خواهیم کرد.با تشکر از دوستان عزیز، منظورم از انعطاف پذیری این بود که مثلا ممکنه ما سه تا فیلد یونیک داشته باشیم اونوقت مثالا 20 تا سطر رو بنویسیم که توی اون 20 تا مقادیر 2 تا از فیلدها دائما تکرار میشن،اما فیلد سوم باید متفاوت باشه و این قضیه در رکوردهای بعدی ممکنه به گونه دیگه ای باشه