مزییت استفاده از فیلد identify

[rezaei manesh]

سلام
من جدیدا همیشه برای همه جدول هام یک فیلد auto Number می گیرم و اونو کلید می کنم و از اون در برنامه استفاده می کنم و کاربر هم اونو نمی بینه
اما الان یه پروژه دارم که طرف می گه که نیاز به این فیلد نیست من یک فیلد کد داریم که منحصر به فرد هست و چون خیلی مهم هست که حتما منحصر به فرد باشه باید خوب چک بشه و دیگه نیاز به اون فیلد identify نیست
خوب اون طوری من راحت تر بودم
می گه اگه می خوای از اون استفاده کنی پس یه دلیل محکم و علمی برای کارت بیار ؟
چی بگم اصلا کدوم بهتره؟

[AminSobati]

زمانی که فیلد یونیک دارید، الزامی به Identity نیست. ولی دلایلی وجود داره که حتی با داشتن فیلد یونیک باز هم میشه از Identity استفاده کرد و بلعکس، دلایلی هست که حتی المقدور از Identity استفاده نکنیم! در کل این موضوع، نوعی سبک سنگین کردن هستش:
قوائد طراحی دیتابیس میگه وقتی فیلد یونیک دارید، ازش استفاده کنین و فیلد دیگه ای اضافه نکنید، اما وسواس روی Performance میگه فیلد Identity چون معمولا INT هستش حجمش کمه و از طرفی Ever Increasing هست. بدین معنی که وقتی روی این فیلد Clustered Index میسازید، همیشه جدید ترین رکورد به انتهای جدول اضافه میشه و Fragmentation بر اثر ورود اطلاعات کمتر خواهد بود. همچنین چون این PK به احتمال زیاد نقش FK رو در بعضی جداول خواهد داشت، Join روی فیلد سبکی مثل INT کمی سریعتر خواهد بود در مقایسه با اینکه فیلد ما مثلا کد ملی افراد، متشکل از چندین کاراکتر باشه!
در مقابل، وجود Identity شاید موقع Replication کمی سناریو رو مشکل کنه. بحث یونیک بودن اعداد تولید شده توسط Identity در کلیه شعبه های دیتابیس مطرحه. باید حتما از Identity Range استفاده کرد یا Identity رو با فیلد دیگه ای مثل SiteID ترکیب کنید تا یونیک بشه در حالیکه شاید فیلد اصلی یونیک که در جدول وجود داره، مقادیرش به گونه ای تولید بشه که در کلیه شعبه ها یونیک باشه.
اما من اگر جای شما بودم چکار میکردم:
اگر فیلد یونیک موجود، تعداد کاراکترهاش زیاده (مثلا 10 کاراکتر یا بیشتر) ترجیحا Identity اضافه میکنم، در غیر اینصورت خود اون فیلد مناسبه برای PK شدن.

[rezaei manesh]

با سپاس فراوان از توضیحات شما
فیلد من تز نوع char و حداکثر با طول 3 کاراکتر هست که با توجه به توضیحات شما من همون رو pk می کنم اما من ایت قسمت از توضیحات شما رو درست نفهمیدم ( کلیه شعبه های دیتابیس -Identity رو با فیلد دیگه ای مثل SiteIDترکیب کنید)


در مقابل، وجود Identity شاید موقع Replication کمی سناریو رو مشکل کنه. بحث یونیک بودن اعداد تولید شده توسط Identity در کلیه شعبه های دیتابیس مطرحه. باید حتما از Identity Range استفاده کرد یا Identity رو با فیلد دیگه ای مثل SiteID ترکیب کنید تا یونیک بشه در حالیکه شاید فیلد اصلی یونیک که در جدول وجود داره، مقادیرش به گونه ای تولید بشه که در کلیه شعبه ها یونیک باشه.

[AminSobati]

یعنی مثلا تهران اگر کدش 1 باشه، عدد 1 برای همه رکوردهای وارد شده در تهران ثبت میشه و این عدد در کنار فیلد Identity یونیک باشه. حالا اگر کد مشهد 2 باشه، اون هم با فیلد Identity یونیک میشه. پس وقتی با Replication این رکوردها در یک دیتابیس مرکزی قرار بگیرند، اعداد Identity اگر هم تکراری باشن برای دو شهر، در ترکیب با کد، یونیک میشن