آیا برای رعایت اصول طراحی بانک اطلاعاتی هر جدول باید دارای یک کلید اصلی باشد؟

[sajad_3dmax]

با عرض سلام.
بنده در طراحی بانک اطلاعاتی کتابخانه یک جدول برای مدیریت درنظرگرفته ام که در آن مواردی مانند مدت امانت کتابها، تعداد تمدید یک کتاب و تعداد کتابهایی که یک عضو میتواند در امانت داشته باشد توسط مدیرمشخص میشوند.این جدول کلیدی ندارد.آیا برای اینکه اصول طراحی بانک اطلاعاتی را رعایت کرده باشم باید حتما یک فیلد مانند Auto Number برای آن قرار دهم؟
با تشکر فراوان

[mehran_sh_t]

سلام
تا جایی که من میبینم، این جدول فقط باید یک رکورد داشته باشه! اگر اینطوره، نه، هیچ اجباری نیست.

[sajad_3dmax]

سلام
تا جایی که من میبینم، این جدول فقط باید یک رکورد داشته باشه! اگر اینطوره، نه، هیچ اجباری نیست.

تشکر.حق با شماست.اما سوال اصلی بنده اینه که آیا این جمله درسته که:هر جدولی حتما باید کلید داشته باشه و الا تحلیل ما اشتباه ست؟؟؟!

[Galawij]

سلام دوست عزیز،
در مورد تحلیل جدول شما، چون نظرات و عقاید مسئولین کتابخانه همیشه ثابت نیست و تغییر می کند، بنابراین شما یک فیلد با نام تاریخ هم به جدولتون اضافه کنید تا مشخص شود که این تصمیمات برای چه تاریخی در نظر گرفته شده است؟
در این صورت جدول شما همواره یک رکورد ندارد و ممکن هست در بازه های زمانی مختلف، تصمیمات متفاوتی گرفته شود.
از لحاظ طراحی همه جداول یک کلید کاندید دارند که لزوماً Autonumber نیست، در اصل یک کلید کاندید از تکرار مقادیر سطری یک جدول جلوگیری می کند،که این امر بحث یکپارچگی بانک اطلاعاتی را تظمین می کند. علاوه بر اینکه در گزارشات هم خیلی موثر هستند.
برای مورد شما یک فیلد Autonumber جواب میدهد(با توجه به اینکه هیچ کدام از مقادیر فیلدها، مقدار یکتایی ندارند).

[Xcalivorse]

بله. کلید اصلی علاوه بر خاصیت یکتایی باید انفرادی هم باشه. کلید اصلی نباید به صورت ترکیبی طراحی بشه. هر چند که پایگاه های داده این امکان رو فراهم میکنند ولی ترکیبی در نظر گرفتن کلید اصلی خلاف اصول طراحیه.

[sajad_3dmax]

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

[sajad_3dmax]

کلید اصلی نباید به صورت ترکیبی طراحی بشه. هر چند که پایگاه های داده این امکان رو فراهم میکنند ولی ترکیبی در نظر گرفتن کلید اصلی خلاف اصول طراحیه.
خوب پس اگر نخواهیم اینکار را انجام دهیم ،در جداولی که ارتباط چند به چند را فراهم میکنند باید چکار کنیم؟

[sina_oonline]

خوب پس اگر نخواهیم اینکار را انجام دهیم ،در جداولی که ارتباط چند به چند را فراهم میکنند باید چکار کنیم؟

من هم با شما موافقم.البته منظور این دوستمون برای من واضح نبود چون برای رابطه های many to many به هر حال به کلید بیگانه نیاز داریم البته نیاز نیست به جدول های خودمون کلید بیگانه بدیم بلکه میشه جدول سومی درست کرد با دو تا ستون حاوری کلید های یگانه دو تا جدول

و اما در مورد سوال اصلی تا اونجایی که من میدونم تو اکثر فریم ورک های معروف لایه persistence وجود id اجباریه بنابر این فکر می کنم باعث بهبود عملکرد پایگاه بشه..

[m0hammad_01]

سلام دوست عزیز،
در مورد تحلیل جدول شما، چون نظرات و عقاید مسئولین کتابخانه همیشه ثابت نیست و تغییر می کند، بنابراین شما یک فیلد با نام تاریخ هم به جدولتون اضافه کنید تا مشخص شود که این تصمیمات برای چه تاریخی در نظر گرفته شده است؟
در این صورت جدول شما همواره یک رکورد ندارد و ممکن هست در بازه های زمانی مختلف، تصمیمات متفاوتی گرفته شود.
از لحاظ طراحی همه جداول یک کلید کاندید دارند که لزوماً Autonumber نیست، در اصل یک کلید کاندید از تکرار مقادیر سطری یک جدول جلوگیری می کند،که این امر بحث یکپارچگی بانک اطلاعاتی را تظمین می کند. علاوه بر اینکه در گزارشات هم خیلی موثر هستند.
برای مورد شما یک فیلد Autonumber جواب میدهد(با توجه به اینکه هیچ کدام از مقادیر فیلدها، مقدار یکتایی ندارند).

من هم با اجازه ، نظر شما رو دارم.


بنده هم خدمت شما عرض سلام دارم.
خوب.با یک رکورد هم میتوان اینکار را انجام داد.هر وقت نیاز به تغییر بود آنرا ویرایش میکنم(کاربر)چرا حجم اطلاعات ذخیره شده در بانک را بالا ببرم؟
در ضمن درصورت استفاده از پیشنهاد شما(استفاده از تاریخ) میتوانم همین فیلد را که حاوی تاریخ و ساعت است کلید در نظر بگیرم.درست است

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