چالشی در مورد استفاده از نوع داده uniqueidentifier به عنوان کلید اصلی

[morteza57]

عرض سلام خدمت تمامی اساتید طراحی دیتابیس
بنده در زمینه طراحی دیتابیس با مشکلی روبرو شده ام که امیدوارم دوستان بتوانند راه حل مناسبی برای آن ارائه نمایند.
اینجانب در حال حاضر همراه با یک تیم برنامه نویس، در حال نوشتن یک نرم افزار نسبتا بزرگ می باشم که یک بخش آن اتوماسیون اداری و دبیرخانه می باشد. این نرم افزار باید قابلیت Replication اطلاعات و تعدادی دیگر از قابلیت ها را داشته باشد.
بهترین گزینه ای که در حال حاضر برای استفاده از کلید اصلی داریم، uniqueidentifier می باشد. این نوع داده در حقیقت تمام خواصی که ما از آن انتظار داریم را دارا هست ولی مشکلاتی دارد که ما را در استفاده از آن مردد نموده است. (موارد ذکر شده در زیر با توجه به دانش بنده و مطالعات مربوطه می باشد و از صحت کامل آن ها مطمئن نیستم)
حجم اطلاعاتی که وارد جداول می شوند و در حقیقت در سیستم در حال جریان هستند بسیار زیاد است و با توجه به گذشت زمان، همچنان افزایش می یابد. با توجه به اینکه توصیه می شود که هنگامی که از این نوع فیلد استفاده می شود، آن را Cluster نکنیم، آیا این مسئله راندمان سیستم را با این حجم اطلاعات دچار مشکل نمی کند؟
با توجه به اینکه این نوع داده 16 بایت را مورد استفاده قرار می دهد، آیا این مسئله بخصوص در استفاه از Join ها و Where Condition راندمان سیستم را با مشکل مواجه نمی کند؟
اگر این نوع داده را به عنوان کلید اصلی استفاده کنیم، باید یک فیلد دیگر نیز از نوع DateTime به جدول اضافه کنیم تا قابلیت Sort را ایجاد نماییم.
البته راه های دیگری مانند استفاده از Composite Key و غیره را هم بررسی نموده ام ولی این راه حل ها هم مشکلات خاص خودشان را دارند.
با توجه به مواردی در که در بالا اشاره کردم و سایر موارد، چه راه حلی به من پیشنهاد می کنید؟
بسیار متشکرم

[AminSobati]

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

- مزایای GUID:
- در هر جدول و هر دیتابیس، رکورد شما یونیک خواهد بود و نگرانیی از بابت نحوه تولید اون نخواهید داشت. این موضوع بیشتر در Replication حائز اهمیت میشه

- معایب GUID:
- معمولا بهتره PK بصورت Clustered باشه (استثناهایی هم وجود داره) لذا وقتی GUID رو بعنوان PK Clustered انتخاب میکنیم، این فیلد در تمام ایندکسهای Non Clustered هم شرکت خواهد کرد. هم افزایش حجم رو به دنبال خواهد داشت (ولی قابل اغماض هست) و هم برای رجوع از ایندکس Non Clustered به Clustered که مثل Join رفتار میشه، این مقایسه طولانی تر از مقایسه فرضا یک فیلد INT خواهد بود. صرف نظر از ایندکسها، شرکت کردن GUID بعنوان FK در سایر جداول و Join کردنشون، باز مشکل مقایسه رو داره (به خاطر تعداد بایتهای بیشتر)
(پاورقی: برای تست میتونین دو جدول با اطلاعات تولید کنین و سرعت Join رو آزمایش کنید. هم در حالت GUID و همINT. شخصا این مورد رو تست نکردم)

- مزایای INT (با خاصیت Identity):
- حجم کم (4 بایت) باعث میشه مقایسه هم در ایندکسها و هم در Joinها کوتاه تر باشه.
- دنبال کردن یک رکورد در چند جدول که ارتباط دارند، بصورت چشمی راحت تر خواهد بود

معایب INT (با خاصیت Identity):
- در Replication باید مراقب Identity Range بود! رکوردهایی که از سایر نقاط به دیتابیس مرکزی منتقل میشن، به راحتی Duplicate PK تولید میکنند. لذا یک فیلد مثل SiteID که TinyInt هم میتونه باشه در نظر میگیریم که با فیلد فیلد اصلی PK بشن. این ما رو به عیب دوم منتهی میکنه!
- وقتی فیلد دومی در کار باشه، PK ما Composite خواهد بود و در تمام Joinها باید حتما این دو فیلد رو مقایسه کنیم. اما به نظر میرسه هنوز تعداد بایتهایی که مقایسه میشن از GUID کمتره.
(پا ورقی: عیب دوم میتونه به حسن تبدیل بشه چرا که در بسیاری از سناریوها وجود این فیلد از بابت دیگه ای هم ضروریه. در نظر بگیرید که PK ما از GUID استفاده کرده. وقتی Replication صورت میگیره و اطلاعات از چند شهر به مرکز منتقل میشه، ممکنه نیاز داشته باشید در مرکز بتونید به تفکیک شهرها پردازش انجام بدین. پس داشتن فیلدی مثل SiteID ضروری به نظر میرسه حتی با داشتن GUID)

نتیجه گیری:
من INT رو ترجیح میدم چرا که انعطاف پذیری کامل داره و فیلد SiteID هم با دو منظور برای ما کاربرد خواهد داشت. ناگفته نماند دیتابیسهای متعددی دیدم که از GUID بعنوان PK استفاده میکردند و مشکلی هم نبوده. دیتابیسهایی که طراحی کردم همیشه INT نقش PK داشته که اونها هم بی مشکل کار کردند.

[aghamirzaei_b]

از Int برای PK استفاده كنید.
برای Replication باید برای هر Subscriber یك رنج مشخص كنید.
هیچ مشكلی پیدا نخواهید كرد. از GUID هم خیلی بهتره